Vulnerability Report
- Name:
- unknown
- Type:
- sbom-file
- Date:
- 2025-06-03T13:06:46.869243+01:00
Critical
17
High
918
Medium
1914
Low
24
Unknown
0
| Name | Version | Type | Vulnerability | Severity | State | Fixed In | Description | Related URLs | PURL |
|---|---|---|---|---|---|---|---|---|---|
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3079 | High | N/A | Type confusion in V8 in Google Chrome prior to 114.0.5735.110 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) | ["http://packetstormsecurity.com/files/176211/Chrome-V8-Type-Confusion.html","http://packetstormsecurity.com/files/176212/Chrome-V8-Type-Confusion-New-Sandbox-Escape.html","https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop.html","https://crbug.com/1450481","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DYTXO5E3FI3I2ETDP3HF4SHYYTFMKMIC/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U4OXTNIZY4JYHJT7CVLPAJQILI6BISVM/","https://security.gentoo.org/glsa/202311-11","https://security.gentoo.org/glsa/202401-34","https://www.couchbase.com/alerts/","https://www.debian.org/security/2023/dsa-5420","http://packetstormsecurity.com/files/176211/Chrome-V8-Type-Confusion.html","http://packetstormsecurity.com/files/176212/Chrome-V8-Type-Confusion-New-Sandbox-Escape.html","https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop.html","https://crbug.com/1450481","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DYTXO5E3FI3I2ETDP3HF4SHYYTFMKMIC/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U4OXTNIZY4JYHJT7CVLPAJQILI6BISVM/","https://security.gentoo.org/glsa/202311-11","https://security.gentoo.org/glsa/202401-34","https://www.couchbase.com/alerts/","https://www.debian.org/security/2023/dsa-5420"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0266 | High | fixed |
|
A use after free vulnerability exists in the ALSA PCM package in the Linux Kernel. SNDRV_CTL_IOCTL_ELEM_{READ|WRITE}32 is missing locks that can be used in a use-after-free that can result in a priviledge escalation to gain ring0 access from the system user. We recommend upgrading past commit 56b88b50565cd8b946a2d00b0c83927b7ebb055e | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4","https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e","https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.10/alsa-pcm-move-rwsem-lock-inside-snd_ctl_elem_read-to-prevent-uaf.patch?id=72783cf35e6c55bca84c4bb7b776c58152856fd4","https://github.com/torvalds/linux/commit/56b88b50565cd8b946a2d00b0c83927b7ebb055e","https://github.com/torvalds/linux/commit/becf9e5d553c2389d857a3c178ce80fdb34a02e1","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-1086 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_verdict_init() function allows positive values as drop error within the hook verdict, and hence the nf_hook_slow() function can cause a double free vulnerability when NF_DROP is issued with a drop error which resembles NF_ACCEPT. We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660. | ["http://www.openwall.com/lists/oss-security/2024/04/10/22","http://www.openwall.com/lists/oss-security/2024/04/10/23","http://www.openwall.com/lists/oss-security/2024/04/14/1","http://www.openwall.com/lists/oss-security/2024/04/15/2","http://www.openwall.com/lists/oss-security/2024/04/17/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660","https://github.com/Notselwyn/CVE-2024-1086","https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://news.ycombinator.com/item?id=39828424","https://pwning.tech/nftables/","https://security.netapp.com/advisory/ntap-20240614-0009/","http://www.openwall.com/lists/oss-security/2024/04/10/22","http://www.openwall.com/lists/oss-security/2024/04/10/23","http://www.openwall.com/lists/oss-security/2024/04/14/1","http://www.openwall.com/lists/oss-security/2024/04/15/2","http://www.openwall.com/lists/oss-security/2024/04/17/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f342de4e2f33e0e39165d8639387aa6c19dff660","https://github.com/Notselwyn/CVE-2024-1086","https://kernel.dance/f342de4e2f33e0e39165d8639387aa6c19dff660","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://news.ycombinator.com/item?id=39828424","https://pwning.tech/nftables/","https://security.netapp.com/advisory/ntap-20240614-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53104 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming. | ["https://git.kernel.org/stable/c/1ee9d9122801eb688783acd07791f2906b87cb4f","https://git.kernel.org/stable/c/467d84dc78c9abf6b217ada22b3fdba336262e29","https://git.kernel.org/stable/c/575a562f7a3ec2d54ff77ab6810e3fbceef2a91d","https://git.kernel.org/stable/c/622ad10aae5f5e03b7927ea95f7f32812f692bb5","https://git.kernel.org/stable/c/684022f81f128338fe3587ec967459669a1204ae","https://git.kernel.org/stable/c/95edf13a48e75dc2cc5b0bc57bf90d6948a22fe8","https://git.kernel.org/stable/c/beced2cb09b58c1243733f374c560a55382003d6","https://git.kernel.org/stable/c/ecf2b43018da9579842c774b7f35dbe11b5c38dd","https://git.kernel.org/stable/c/faff5bbb2762c44ec7426037b3000e77a11d6773"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53197 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devices A bogus device can provide a bNumConfigurations value that exceeds the initial value used in usb_get_configuration for allocating dev->config. This can lead to out-of-bounds accesses later, e.g. in usb_destroy_configuration. | ["https://git.kernel.org/stable/c/0b4ea4bfe16566b84645ded1403756a2dc4e0f19","https://git.kernel.org/stable/c/379d3b9799d9da953391e973b934764f01e03960","https://git.kernel.org/stable/c/62dc01c83fa71e10446ee4c31e0e3d5d1291e865","https://git.kernel.org/stable/c/920a369a9f014f10ec282fd298d0666129379f1b","https://git.kernel.org/stable/c/9887d859cd60727432a01564e8f91302d361b72b","https://git.kernel.org/stable/c/9b8460a2a7ce478e0b625af7c56d444dc24190f7","https://git.kernel.org/stable/c/b521b53ac6eb04e41c03f46f7fe452e4d8e9bcca","https://git.kernel.org/stable/c/b8f8b81dabe52b413fe9e062e8a852c48dd0680d","https://git.kernel.org/stable/c/b909df18ce2a998afef81d58bbd1a05dc0788c40"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36971 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: fix __dst_negative_advice() race __dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF. RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst). Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order. Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves. Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks. Many thanks to Clement Lecigne for tracking this issue. This old bug became visible after the blamed commit, using UDP sockets. | ["https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13","https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6","https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508","https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4","https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e","https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc","https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72","https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf","https://git.kernel.org/stable/c/051c0bde9f0450a2ec3d62a86d2a0d2fad117f13","https://git.kernel.org/stable/c/2295a7ef5c8c49241bff769e7826ef2582e532a6","https://git.kernel.org/stable/c/5af198c387128a9d2ddd620b0f0803564a4d4508","https://git.kernel.org/stable/c/81dd3c82a456b0015461754be7cb2693991421b4","https://git.kernel.org/stable/c/92f1655aa2b2294d0b49925f3b875a634bd3b59e","https://git.kernel.org/stable/c/b8af8e6118a6605f0e495a58d591ca94a85a50fc","https://git.kernel.org/stable/c/db0082825037794c5dba9959c9de13ca34cc5e72","https://git.kernel.org/stable/c/eacb8b195579c174a6d3e12a9690b206eb7f28cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53150 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix out of bounds reads when finding clock sources The current USB-audio driver code doesn't check bLength of each descriptor at traversing for clock descriptors. That is, when a device provides a bogus descriptor with a shorter bLength, the driver might hit out-of-bounds reads. For addressing it, this patch adds sanity checks to the validator functions for the clock descriptor traversal. When the descriptor length is shorter than expected, it's skipped in the loop. For the clock source and clock multiplier descriptors, we can just check bLength against the sizeof() of each descriptor type. OTOH, the clock selector descriptor of UAC2 and UAC3 has an array of bNrInPins elements and two more fields at its tail, hence those have to be checked in addition to the sizeof() check. | ["https://git.kernel.org/stable/c/096bb5b43edf755bc4477e64004fa3a20539ec2f","https://git.kernel.org/stable/c/45a92cbc88e4013bfed7fd2ccab3ade45f8e896b","https://git.kernel.org/stable/c/74cb86e1006c5437b1d90084d22018da30fddc77","https://git.kernel.org/stable/c/a3dd4d63eeb452cfb064a13862fb376ab108f6a6","https://git.kernel.org/stable/c/a632bdcb359fd8145e86486ff8612da98e239acd","https://git.kernel.org/stable/c/ab011f7439d9bbfd34fd3b9cef4b2d6d952c9bb9","https://git.kernel.org/stable/c/da13ade87a12dd58829278bc816a61bea06a56a9","https://git.kernel.org/stable/c/ea0fa76f61cf8e932d1d26e6193513230816e11d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2586 | High | N/A | It was discovered that a nft object or expression could reference a nft set on a different nft table, leading to a use-after-free once that table was deleted. | ["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586","https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://www.openwall.com/lists/oss-security/2022/08/09/5","https://www.zerodayinitiative.com/advisories/ZDI-22-1118/","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2586","https://lore.kernel.org/netfilter-devel/20220809170148.164591-1-cascardo@canonical.com/T/#t","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://www.openwall.com/lists/oss-security/2022/08/09/5","https://www.vicarius.io/vsociety/posts/use-after-free-vulnerability-linked-chain-between-nft-tables-cve-2022-2586","https://www.zerodayinitiative.com/advisories/ZDI-22-1118/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50302 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report. | ["https://git.kernel.org/stable/c/05ade5d4337867929e7ef664e7ac8e0c734f1aaf","https://git.kernel.org/stable/c/177f25d1292c7e16e1199b39c85480f7f8815552","https://git.kernel.org/stable/c/1884ab3d22536a5c14b17c78c2ce76d1734e8b0b","https://git.kernel.org/stable/c/3f9e88f2672c4635960570ee9741778d4135ecf5","https://git.kernel.org/stable/c/492015e6249fbcd42138b49de3c588d826dd9648","https://git.kernel.org/stable/c/9d9f5c75c0c7f31766ec27d90f7a6ac673193191","https://git.kernel.org/stable/c/d7dc68d82ab3fcfc3f65322465da3d7031d4ab46","https://git.kernel.org/stable/c/e7ea60184e1e88a3c9e437b3265cbb6439aa7e26"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2588 | High | fixed |
|
It was discovered that the cls_route filter implementation in the Linux kernel would not remove an old filter from the hashtable before freeing it if its handle had the value 0. | ["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588","https://github.com/Markakd/CVE-2022-2588","https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://ubuntu.com/security/notices/USN-5588-1","https://www.openwall.com/lists/oss-security/2022/08/09/6","https://www.zerodayinitiative.com/advisories/ZDI-22-1117/","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2588","https://github.com/Markakd/CVE-2022-2588","https://lore.kernel.org/netdev/20220809170518.164662-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5557-1","https://ubuntu.com/security/notices/USN-5560-1","https://ubuntu.com/security/notices/USN-5560-2","https://ubuntu.com/security/notices/USN-5562-1","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://ubuntu.com/security/notices/USN-5582-1","https://ubuntu.com/security/notices/USN-5588-1","https://www.openwall.com/lists/oss-security/2022/08/09/6","https://www.zerodayinitiative.com/advisories/ZDI-22-1117/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-34918 | High | fixed |
|
An issue was discovered in the Linux kernel through 5.18.9. A type confusion bug in nft_set_elem_init (leading to a buffer overflow) could be used by a local attacker to escalate privileges, a different vulnerability than CVE-2022-32250. (The attacker can obtain root access, but must start with an unprivileged user namespace to obtain CAP_NET_ADMIN access.) This can be fixed in nft_setelem_parse_data in net/netfilter/nf_tables_api.c. | ["http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html","http://www.openwall.com/lists/oss-security/2022/07/05/1","http://www.openwall.com/lists/oss-security/2022/08/06/5","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6","https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u","https://security.netapp.com/advisory/ntap-20220826-0004/","https://www.debian.org/security/2022/dsa-5191","https://www.openwall.com/lists/oss-security/2022/07/02/3","https://www.randorisec.fr/crack-linux-firewall/","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://packetstormsecurity.com/files/168543/Netfilter-nft_set_elem_init-Heap-Overflow-Privilege-Escalation.html","http://www.openwall.com/lists/oss-security/2022/07/05/1","http://www.openwall.com/lists/oss-security/2022/08/06/5","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e6bc1f6cabcd30aba0b11219d8e01b952eacbb6","https://lore.kernel.org/netfilter-devel/cd9428b6-7ffb-dd22-d949-d86f4869f452%40randorisec.fr/T/#u","https://security.netapp.com/advisory/ntap-20220826-0004/","https://www.debian.org/security/2022/dsa-5191","https://www.openwall.com/lists/oss-security/2022/07/02/3","https://www.randorisec.fr/crack-linux-firewall/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0995 | High | fixed |
|
An out-of-bounds (OOB) memory write flaw was found in the Linux kernel’s watch_queue event notification subsystem. This flaw can overwrite parts of the kernel state, potentially allowing a local user to gain privileged access or cause a denial of service on the system. | ["http://packetstormsecurity.com/files/166770/Linux-watch_queue-Filter-Out-Of-Bounds-Write.html","http://packetstormsecurity.com/files/166815/Watch-Queue-Out-Of-Bounds-Write.html","https://bugzilla.redhat.com/show_bug.cgi?id=2063786","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93ce93587d36493f2f86921fa79921b3cba63fbb","https://security.netapp.com/advisory/ntap-20220429-0001/","http://packetstormsecurity.com/files/166770/Linux-watch_queue-Filter-Out-Of-Bounds-Write.html","http://packetstormsecurity.com/files/166815/Watch-Queue-Out-Of-Bounds-Write.html","https://bugzilla.redhat.com/show_bug.cgi?id=2063786","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93ce93587d36493f2f86921fa79921b3cba63fbb","https://security.netapp.com/advisory/ntap-20220429-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0386 | High | fixed |
|
A flaw was found in the Linux kernel, where unauthorized access to the execution of the setuid file with capabilities was found in the Linux kernel’s OverlayFS subsystem in how a user copies a capable file from a nosuid mount into another mount. This uid mapping bug allows a local user to escalate their privileges on the system. | ["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20230420-0004/","https://www.debian.org/security/2023/dsa-5402","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f11ada10d0a","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20230420-0004/","https://www.debian.org/security/2023/dsa-5402"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-44466 | High | fixed |
|
An issue was discovered in net/ceph/messenger_v2.c in the Linux kernel before 6.4.5. There is an integer signedness error, leading to a buffer overflow and remote code execution via HELLO or one of the AUTH frames. This occurs because of an untrusted length taken from a TCP packet in ceph_decode_32. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97","https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph","https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97","https://security.netapp.com/advisory/ntap-20231116-0003/","https://www.spinics.net/lists/ceph-devel/msg57909.html","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a282a2f10539dce2aa619e71e1817570d557fc97","https://github.com/google/security-research/security/advisories/GHSA-jg27-jx6w-xwph","https://github.com/torvalds/linux/commit/a282a2f10539dce2aa619e71e1817570d557fc97","https://security.netapp.com/advisory/ntap-20231116-0003/","https://www.spinics.net/lists/ceph-devel/msg57909.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3338 | Medium | fixed |
|
A null pointer dereference flaw was found in the Linux kernel's DECnet networking protocol. This issue could allow a remote user to crash the system. | ["https://access.redhat.com/security/cve/CVE-2023-3338","https://bugzilla.redhat.com/show_bug.cgi?id=2218618","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://seclists.org/oss-sec/2023/q2/276","https://security.netapp.com/advisory/ntap-20230824-0005/","https://www.debian.org/security/2023/dsa-5480","https://access.redhat.com/security/cve/CVE-2023-3338","https://bugzilla.redhat.com/show_bug.cgi?id=2218618","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://seclists.org/oss-sec/2023/q2/276","https://security.netapp.com/advisory/ntap-20230824-0005/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-36946 | High | fixed |
|
nfqnl_mangle in net/netfilter/nfnetlink_queue.c in the Linux kernel through 5.18.14 allows remote attackers to cause a denial of service (panic) because, in the case of an nf_queue verdict with a one-byte nfta_payload attribute, an skb_pull can encounter a negative skb->len. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://marc.info/?l=netfilter-devel\u0026m=165883202007292\u0026w=2","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=99a63d36cb3ed5ca3aa6fcb64cffbeaf3b0fb164","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://marc.info/?l=netfilter-devel\u0026m=165883202007292\u0026w=2","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35960 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Properly link new fs rules into the tree Previously, add_rule_fg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, create_flow_handle tries hard to find and reference already existing identical rules instead of creating new ones. These two behaviors can result in a situation where create_flow_handle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because del_sw_hw_rule, invoked on rule deletion, assumes node->parent is != NULL. This happened in the wild, due to another bug related to incorrect handling of duplicate pkt_reformat ids, which lead to the code in create_flow_handle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1]. This patch changes add_rule_fg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in create_flow_handle. | ["https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423","https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f","https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801","https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0","https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64","https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453","https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d","https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2","https://git.kernel.org/stable/c/1263b0b26077b1183c3c45a0a2479573a351d423","https://git.kernel.org/stable/c/2e8dc5cffc844dacfa79f056dea88002312f253f","https://git.kernel.org/stable/c/3d90ca9145f6b97b38d0c2b6b30f6ca6af9c1801","https://git.kernel.org/stable/c/5cf5337ef701830f173b4eec00a4f984adeb57a0","https://git.kernel.org/stable/c/7aaee12b804c5e0374e7b132b6ec2158ff33dd64","https://git.kernel.org/stable/c/7c6782ad4911cbee874e85630226ed389ff2e453","https://git.kernel.org/stable/c/adf67a03af39095f05d82050f15813d6f700159d","https://git.kernel.org/stable/c/de0139719cdda82806a47580ca0df06fc85e0bd2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-5178 | High | fixed |
|
A use-after-free vulnerability was found in drivers/nvme/target/tcp.c` in `nvmet_tcp_free_crypto` due to a logical bug in the NVMe/TCP subsystem in the Linux kernel. This issue may allow a malicious user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation. | ["https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7551","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2023:7557","https://access.redhat.com/errata/RHSA-2023:7559","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0386","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/security/cve/CVE-2023-5178","https://bugzilla.redhat.com/show_bug.cgi?id=2241924","https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7551","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2023:7557","https://access.redhat.com/errata/RHSA-2023:7559","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0386","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/security/cve/CVE-2023-5178","https://bugzilla.redhat.com/show_bug.cgi?id=2241924","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/","https://security.netapp.com/advisory/ntap-20231208-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2156 | High | fixed |
|
A flaw was found in the networking subsystem of the Linux kernel within the handling of the RPL protocol. This issue results from the lack of proper handling of user-supplied data, which can lead to an assertion failure. This may allow an unauthenticated remote attacker to create a denial of service condition on the system. | ["http://www.openwall.com/lists/oss-security/2023/05/17/8","http://www.openwall.com/lists/oss-security/2023/05/17/9","http://www.openwall.com/lists/oss-security/2023/05/18/1","http://www.openwall.com/lists/oss-security/2023/05/19/1","https://bugzilla.redhat.com/show_bug.cgi?id=2196292","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230622-0001/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5453","https://www.zerodayinitiative.com/advisories/ZDI-23-547/","http://www.openwall.com/lists/oss-security/2023/05/17/8","http://www.openwall.com/lists/oss-security/2023/05/17/9","http://www.openwall.com/lists/oss-security/2023/05/18/1","http://www.openwall.com/lists/oss-security/2023/05/19/1","https://bugzilla.redhat.com/show_bug.cgi?id=2196292","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230622-0001/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5453","https://www.zerodayinitiative.com/advisories/ZDI-23-547/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27405 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs It is observed sometimes when tethering is used over NCM with Windows 11 as host, at some instances, the gadget_giveback has one byte appended at the end of a proper NTB. When the NTB is parsed, unwrap call looks for any leftover bytes in SKB provided by u_ether and if there are any pending bytes, it treats them as a separate NTB and parses it. But in case the second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that were parsed properly in the first NTB and saved in rx_list are dropped. Adding a few custom traces showed the following: [002] d..1 7828.532866: dwc3_gadget_giveback: ep1out: req 000000003868811a length 1025/16384 zsI ==> 0 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025 [002] d..1 7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400 [002] d..1 7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10 [002] d..1 7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames In this case, the giveback is of 1025 bytes and block length is 1024. The rest 1 byte (which is 0x00) won't be parsed resulting in drop of all datagrams in rx_list. Same is case with packets of size 2048: [002] d..1 7828.557948: dwc3_gadget_giveback: ep1out: req 0000000011dfd96e length 2049/16384 zsI ==> 0 [002] d..1 7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342 [002] d..1 7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800 Lecroy shows one byte coming in extra confirming that the byte is coming in from PC: Transfer 2959 - Bytes Transferred(1025) Timestamp((18.524 843 590) - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590) --- Packet 4063861 Data(1024 bytes) Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590) --- Packet 4063863 Data(1 byte) Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722) According to Windows driver, no ZLP is needed if wBlockLength is non-zero, because the non-zero wBlockLength has already told the function side the size of transfer to be expected. However, there are in-market NCM devices that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize. To deal with such devices, it pads an extra 0 at end so the transfer is no longer multiple of wMaxPacketSize. | ["https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48","https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e","https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5","https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca","https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd","https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd","https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151","https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e","https://git.kernel.org/stable/c/059285e04ebb273d32323fbad5431c5b94f77e48","https://git.kernel.org/stable/c/2b7ec68869d50ea998908af43b643bca7e54577e","https://git.kernel.org/stable/c/2cb66b62a5d64ccf09b0591ab86fb085fa491fc5","https://git.kernel.org/stable/c/35b604a37ec70d68b19dafd10bbacf1db505c9ca","https://git.kernel.org/stable/c/57ca0e16f393bb21d69734e536e383a3a4c665fd","https://git.kernel.org/stable/c/76c51146820c5dac629f21deafab0a7039bc3ccd","https://git.kernel.org/stable/c/a31cf46d108dabce3df80b3e5c07661e24912151","https://git.kernel.org/stable/c/c7f43900bc723203d7554d299a2ce844054fab8e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-32250 | High | fixed |
|
net/netfilter/nf_tables_api.c in the Linux kernel through 5.18.1 allows a local user (able to create user/net namespaces) to escalate privileges to root because an incorrect NFT_STATEFUL_EXPR check leads to a use-after-free. | ["http://www.openwall.com/lists/oss-security/2022/06/03/1","http://www.openwall.com/lists/oss-security/2022/06/04/1","http://www.openwall.com/lists/oss-security/2022/06/20/1","http://www.openwall.com/lists/oss-security/2022/07/03/5","http://www.openwall.com/lists/oss-security/2022/07/03/6","http://www.openwall.com/lists/oss-security/2022/08/25/1","http://www.openwall.com/lists/oss-security/2022/09/02/9","https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/","https://bugzilla.redhat.com/show_bug.cgi?id=2092427","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd","https://github.com/theori-io/CVE-2022-32250-exploit","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/","https://security.netapp.com/advisory/ntap-20220715-0005/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://www.openwall.com/lists/oss-security/2022/05/31/1","http://www.openwall.com/lists/oss-security/2022/06/03/1","http://www.openwall.com/lists/oss-security/2022/06/04/1","http://www.openwall.com/lists/oss-security/2022/06/20/1","http://www.openwall.com/lists/oss-security/2022/07/03/5","http://www.openwall.com/lists/oss-security/2022/07/03/6","http://www.openwall.com/lists/oss-security/2022/08/25/1","http://www.openwall.com/lists/oss-security/2022/09/02/9","https://blog.theori.io/research/CVE-2022-32250-linux-kernel-lpe-2022/","https://bugzilla.redhat.com/show_bug.cgi?id=2092427","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/netfilter?id=520778042ccca019f3ffa136dd0ca565c486cedd","https://github.com/theori-io/CVE-2022-32250-exploit","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/MO6Y3TC4WUUNKRP7OQA26OVTZTPCS6F2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/UIZTJOJCVVEJVOQSCHE6IJQKMPISHQ5L/","https://security.netapp.com/advisory/ntap-20220715-0005/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://www.openwall.com/lists/oss-security/2022/05/31/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0742 | High | fixed |
|
Memory leak in icmp6 implementation in Linux Kernel 5.13+ allows a remote attacker to DoS a host by making it go out-of-memory via icmp6 packets of type 130 or 131. We recommend upgrading past commit 2d3916f3189172d5c69d33065c3c21119fe539fc. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc","https://security.netapp.com/advisory/ntap-20220425-0001/","https://www.openwall.com/lists/oss-security/2022/03/15/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2d3916f3189172d5c69d33065c3c21119fe539fc","https://security.netapp.com/advisory/ntap-20220425-0001/","https://www.openwall.com/lists/oss-security/2022/03/15/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27053 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix RCU usage in connect path With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning: ============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from ____sys_sendmsg+0x190/0x430 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158 ___sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data | ["https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f","https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce","https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de","https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2","https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38","https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2","https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7","https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2","https://git.kernel.org/stable/c/205c50306acf58a335eb19fa84e40140f4fe814f","https://git.kernel.org/stable/c/4bfd20d5f5c62b5495d6c0016ee6933bd3add7ce","https://git.kernel.org/stable/c/5800ec78775c0cd646f71eb9bf8402fb794807de","https://git.kernel.org/stable/c/745003b5917b610352f52fe0d11ef658d6471ec2","https://git.kernel.org/stable/c/b4bbf38c350acb6500cbe667b1e2e68f896e4b38","https://git.kernel.org/stable/c/d80fc436751cfa6b02a8eda74eb6cce7dadfe5a2","https://git.kernel.org/stable/c/dd50d3ead6e3707bb0a5df7cc832730c93ace3a7","https://git.kernel.org/stable/c/e556006de4ea93abe2b46cba202a2556c544b8b2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1015 | Medium | fixed |
|
A flaw was found in the Linux kernel in linux/net/netfilter/nf_tables_api.c of the netfilter subsystem. This flaw allows a local user to cause an out-of-bounds write issue. | ["http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/08/25/2","http://www.openwall.com/lists/oss-security/2023/01/13/2","http://www.openwall.com/lists/oss-security/2023/02/23/1","https://bugzilla.redhat.com/show_bug.cgi?id=2065323","https://seclists.org/oss-sec/2022/q1/205","http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/08/25/2","http://www.openwall.com/lists/oss-security/2023/01/13/2","http://www.openwall.com/lists/oss-security/2023/02/23/1","https://bugzilla.redhat.com/show_bug.cgi?id=2065323","https://seclists.org/oss-sec/2022/q1/205"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52696 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/powernv: Add a null pointer check in opal_powercap_init() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. | ["https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664","https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219","https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc","https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1","https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab","https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d","https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0","https://git.kernel.org/stable/c/69f95c5e9220f77ce7c540686b056c2b49e9a664","https://git.kernel.org/stable/c/6b58d16037217d0c64a2a09b655f370403ec7219","https://git.kernel.org/stable/c/9da4a56dd3772570512ca58aa8832b052ae910dc","https://git.kernel.org/stable/c/a67a04ad05acb56640798625e73fa54d6d41cce1","https://git.kernel.org/stable/c/b02ecc35d01a76b4235e008d2dd292895b28ecab","https://git.kernel.org/stable/c/e123015c0ba859cf48aa7f89c5016cc6e98e018d","https://git.kernel.org/stable/c/f152a6bfd187f67afeffc9fd68cbe46f51439be0","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47939 | Critical | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2_TREE_DISCONNECT. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/","https://www.zerodayinitiative.com/advisories/ZDI-22-1690/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://github.com/torvalds/linux/commit/cf6531d98190fa2cf92a6d8bbc8af0a4740a223c","https://www.secpod.com/blog/zero-day-server-message-block-smb-server-in-linux-kernel-5-15-has-a-critical-vulnerability-patch-ksmbd-immediately/","https://www.zerodayinitiative.com/advisories/ZDI-22-1690/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35823 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vt: fix unicode buffer corruption when deleting characters This is the same issue that was fixed for the VGA text buffer in commit 39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in the buffer"). The cure is also the same i.e. replace memcpy() with memmove() due to the overlaping buffers. | ["https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f","https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d","https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90","https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1","https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda","https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51","https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d","https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a","https://git.kernel.org/stable/c/0190d19d7651c08abc187dac3819c61b726e7e3f","https://git.kernel.org/stable/c/1581dafaf0d34bc9c428a794a22110d7046d186d","https://git.kernel.org/stable/c/1ce408f75ccf1e25b3fddef75cca878b55f2ac90","https://git.kernel.org/stable/c/2933b1e4757a0a5c689cf48d80b1a2a85f237ff1","https://git.kernel.org/stable/c/7529cbd8b5f6697b369803fe1533612c039cabda","https://git.kernel.org/stable/c/994a1e583c0c206c8ca7d03334a65b79f4d8bc51","https://git.kernel.org/stable/c/fc7dfe3d123f00e720be80b920da287810a1f37d","https://git.kernel.org/stable/c/ff7342090c1e8c5a37015c89822a68b275b46f8a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35845 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: dbg-tlv: ensure NUL termination The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it. | ["https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641","https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c","https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7","https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a","https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea","https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209","https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9","https://git.kernel.org/stable/c/71d4186d470e9cda7cd1a0921b4afda737c6f641","https://git.kernel.org/stable/c/783d413f332a3ebec916664b366c28f58147f82c","https://git.kernel.org/stable/c/96aa40761673da045a7774f874487cdb50c6a2f7","https://git.kernel.org/stable/c/c855a1a5b7e3de57e6b1b29563113d5e3bfdb89a","https://git.kernel.org/stable/c/ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea","https://git.kernel.org/stable/c/fabe2db7de32a881e437ee69db32e0de785a6209","https://git.kernel.org/stable/c/fec14d1cdd92f340b9ba2bd220abf96f9609f2a9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2007-2764 | High | N/A | The embedded Linux kernel in certain Sun-Brocade SilkWorm switches before 20070516 does not properly handle a situation in which a non-root user creates a kernel process, which allows attackers to cause a denial of service (oops and device reboot) via unspecified vectors. | ["http://osvdb.org/39117","http://sunsolve.sun.com/search/document.do?assetkey=1-26-102752-1","http://www.securityfocus.com/bid/24036","https://exchange.xforce.ibmcloud.com/vulnerabilities/34495","http://osvdb.org/39117","http://sunsolve.sun.com/search/document.do?assetkey=1-26-102752-1","http://www.securityfocus.com/bid/24036","https://exchange.xforce.ibmcloud.com/vulnerabilities/34495"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52832 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't return unset power in ieee80211_get_tx_power() We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. | ["https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f","https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846","https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62","https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6","https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7","https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea","https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a","https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f","https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18","https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f","https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846","https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62","https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6","https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd671fe87c7","https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea","https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a","https://git.kernel.org/stable/c/e160ab85166e77347d0cbe5149045cb25e83937f","https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47943 | High | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2_WRITE, when there is a large length in the zero DataOffset case. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09","https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09","https://security.netapp.com/advisory/ntap-20230216-0006/","https://www.zerodayinitiative.com/advisories/ZDI-22-1691/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac60778b87e45576d7bfdbd6f53df902654e6f09","https://github.com/torvalds/linux/commit/ac60778b87e45576d7bfdbd6f53df902654e6f09","https://security.netapp.com/advisory/ntap-20230216-0006/","https://www.zerodayinitiative.com/advisories/ZDI-22-1691/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35854 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash The rehash delayed work migrates filters from one region to another according to the number of available credits. The migrated from region is destroyed at the end of the work if the number of credits is non-negative as the assumption is that this is indicative of migration being complete. This assumption is incorrect as a non-negative number of credits can also be the result of a failed migration. The destruction of a region that still has filters referencing it can result in a use-after-free [1]. Fix by not destroying the region if migration failed. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858 CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 | ["https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049","https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121","https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519","https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887","https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1","https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1","https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388","https://git.kernel.org/stable/c/311eeaa7b9e26aba5b3d57b09859f07d8e9fc049","https://git.kernel.org/stable/c/4c89642ca47fb620914780c7c51d8d1248201121","https://git.kernel.org/stable/c/54225988889931467a9b55fdbef534079b665519","https://git.kernel.org/stable/c/813e2ab753a8f8c243a39ede20c2e0adc15f3887","https://git.kernel.org/stable/c/a02687044e124f8ccb427cd3632124a4e1a7d7c1","https://git.kernel.org/stable/c/a429a912d6c779807f4d72a6cc0a1efaaa3613e1","https://git.kernel.org/stable/c/e118e7ea24d1392878ef85926627c6bc640c4388","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3113 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. mtk_vcodec_fw_vpu_init in drivers/media/platform/mtk-vcodec/mtk_vcodec_fw_vpu.c lacks check of the return value of devm_kzalloc() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153053","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e25a89f743b18c029bfbe5e1663ae0c7190912b0","https://bugzilla.redhat.com/show_bug.cgi?id=2153053","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e25a89f743b18c029bfbe5e1663ae0c7190912b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38612 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix invalid unregister error path The error path of seg6_init() is wrong in case CONFIG_IPV6_SEG6_LWTUNNEL is not defined. In that case if seg6_hmac_init() fails, the genl_unregister_family() isn't called. This issue exist since commit 46738b1317e1 ("ipv6: sr: add option to control lwtunnel support"), and commit 5559cea2d5aa ("ipv6: sr: fix possible use-after-free and null-ptr-deref") replaced unregister_pernet_subsys() with genl_unregister_family() in this error path. | ["https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c","https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7","https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45","https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01","https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66","https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4","https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a","https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4","https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925","https://git.kernel.org/stable/c/00e6335329f23ac6cf3105931691674e28bc598c","https://git.kernel.org/stable/c/10610575a3ac2a702bf5c57aa931beaf847949c7","https://git.kernel.org/stable/c/160e9d2752181fcf18c662e74022d77d3164cd45","https://git.kernel.org/stable/c/1a63730fb315bb1bab97edd69ff58ad45e04bb01","https://git.kernel.org/stable/c/3398a40dccb88d3a7eef378247a023a78472db66","https://git.kernel.org/stable/c/646cd236c55e2cb5f146fc41bbe4034c4af5b2a4","https://git.kernel.org/stable/c/85a70ff1e572160f1eeb096ed48d09a1c9d4d89a","https://git.kernel.org/stable/c/c04d6a914e890ccea4a9d11233009a2ee7978bf4","https://git.kernel.org/stable/c/e77a3ec7ada84543e75722a1283785a6544de925"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2639 | High | fixed |
|
An integer coercion error was found in the openvswitch kernel module. Given a sufficiently large number of actions, while copying and reserving memory for a new action of a new flow, the reserve_sfa_size() function does not return -EMSGSIZE as expected, potentially leading to an out-of-bounds write access. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2084479","https://github.com/torvalds/linux/commit/cefa91b2332d7009bc0be5d951d6cbbf349f90f8","https://bugzilla.redhat.com/show_bug.cgi?id=2084479","https://github.com/torvalds/linux/commit/cefa91b2332d7009bc0be5d951d6cbbf349f90f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38623 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Use variable length array instead of fixed size Should fix smatch warning: ntfs_set_label() error: __builtin_memcpy() 'uni->name' too small (20 vs 256) | ["https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef","https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1","https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7","https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f","https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1","https://git.kernel.org/stable/c/1997cdc3e727526aa5d84b32f7cbb3f56459b7ef","https://git.kernel.org/stable/c/1fe1c9dc21ee52920629d2d9b9bd84358931a8d1","https://git.kernel.org/stable/c/3839a9b19a4b70eff6b6ad70446f639f7fd5a3d7","https://git.kernel.org/stable/c/a2de301d90b782ac5d7a5fe32995caaee9ab3a0f","https://git.kernel.org/stable/c/cceef44b34819c24bb6ed70dce5b524bd3e368d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6200 | High | fixed |
|
A race condition was found in the Linux Kernel. Under certain conditions, an unauthenticated attacker from an adjacent network could send an ICMPv6 router advertisement packet, causing arbitrary code execution. | ["https://access.redhat.com/security/cve/CVE-2023-6200","https://bugzilla.redhat.com/show_bug.cgi?id=2250377","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dade3f6a1e4e","https://access.redhat.com/security/cve/CVE-2023-6200","https://bugzilla.redhat.com/show_bug.cgi?id=2250377","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dade3f6a1e4e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-43945 | High | fixed |
|
The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H | ["http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8","https://security.netapp.com/advisory/ntap-20221215-0006/","http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f90497a16e434c2211c66e3de8e77b17868382b8","https://security.netapp.com/advisory/ntap-20221215-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26924 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_set_pipapo: do not free live element Pablo reports a crash with large batches of elements with a back-to-back add/remove pattern. Quoting Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- delete one that was just added ... add_elem("00005000") timeout 100 ms 1) nft_pipapo_remove() removes element 0000000X Then, KASAN shows a splat. Looking at the remove function there is a chance that we will drop a rule that maps to a non-deactivated element. Removal happens in two steps, first we do a lookup for key k and return the to-be-removed element and mark it as inactive in the next generation. Then, in a second step, the element gets removed from the set/map. The _remove function does not work correctly if we have more than one element that share the same key. This can happen if we insert an element into a set when the set already holds an element with same key, but the element mapping to the existing key has timed out or is not active in the next generation. In such case its possible that removal will unmap the wrong element. If this happens, we will leak the non-deactivated element, it becomes unreachable. The element that got deactivated (and will be freed later) will remain reachable in the set data structure, this can result in a crash when such an element is retrieved during lookup (stale pointer). Add a check that the fully matching key does in fact map to the element that we have marked as inactive in the deactivation step. If not, we need to continue searching. Add a bug/warn trap at the end of the function as well, the remove function must not ever be called with an invisible/unreachable/non-existent element. v2: avoid uneeded temporary variable (Stefano) | ["https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487","https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc","https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644","https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46","https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2","https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a","https://git.kernel.org/stable/c/14b001ba221136c15f894577253e8db535b99487","https://git.kernel.org/stable/c/3cfc9ec039af60dbd8965ae085b2c2ccdcfbe1cc","https://git.kernel.org/stable/c/41d8fdf3afaff312e17466e4ab732937738d5644","https://git.kernel.org/stable/c/7a1679e2d9bfa3b5f8755c2c7113e54b7d42bd46","https://git.kernel.org/stable/c/e3b887a9c11caf8357a821260e095f2a694a34f2","https://git.kernel.org/stable/c/ebf7c9746f073035ee26209e38c3a1170f7b349a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38605 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: core: Fix NULL module pointer assignment at card init The commit 81033c6b584b ("ALSA: core: Warn on empty module") introduced a WARN_ON() for a NULL module pointer passed at snd_card object creation, and it also wraps the code around it with '#ifdef MODULE'. This works in most cases, but the devils are always in details. "MODULE" is defined when the target code (i.e. the sound core) is built as a module; but this doesn't mean that the caller is also built-in or not. Namely, when only the sound core is built-in (CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m), the passed module pointer is ignored even if it's non-NULL, and card->module remains as NULL. This would result in the missing module reference up/down at the device open/close, leading to a race with the code execution after the module removal. For addressing the bug, move the assignment of card->module again out of ifdef. The WARN_ON() is still wrapped with ifdef because the module can be really NULL when all sound drivers are built-in. Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would lead to a false-positive NULL module check. Admittedly it won't catch perfectly, i.e. no check is performed when CONFIG_SND=y. But, it's no real problem as it's only for debugging, and the condition is pretty rare. | ["https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1","https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12","https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5","https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434","https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e","https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92","https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811","https://git.kernel.org/stable/c/39381fe7394e5eafac76e7e9367e7351138a29c1","https://git.kernel.org/stable/c/6b8374ee2cabcf034faa34e69a855dc496a9ec12","https://git.kernel.org/stable/c/c935e72139e6d523defd60fe875c01eb1f9ea5c5","https://git.kernel.org/stable/c/d7ff29a429b56f04783152ad7bbd7233b740e434","https://git.kernel.org/stable/c/e007476725730c1a68387b54b7629486d8a8301e","https://git.kernel.org/stable/c/e644036a3e2b2c9b3eee3c61b5d31c2ca8b5ba92","https://git.kernel.org/stable/c/e7e0ca200772bdb2fdc6d43d32d341e87a36f811"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38582 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential hang in nilfs_detach_log_writer() Syzbot has reported a potential hang in nilfs_detach_log_writer() called during nilfs2 unmount. Analysis revealed that this is because nilfs_segctor_sync(), which synchronizes with the log writer thread, can be called after nilfs_segctor_destroy() terminates that thread, as shown in the call trace below: nilfs_detach_log_writer nilfs_segctor_destroy nilfs_segctor_kill_thread --> Shut down log writer thread flush_work nilfs_iput_work_func nilfs_dispose_list iput nilfs_evict_inode nilfs_transaction_commit nilfs_construct_segment (if inode needs sync) nilfs_segctor_sync --> Attempt to synchronize with log writer thread *** DEADLOCK *** Fix this issue by changing nilfs_segctor_sync() so that the log writer thread returns normally without synchronizing after it terminates, and by forcing tasks that are already waiting to complete once after the thread terminates. The skipped inode metadata flushout will then be processed together in the subsequent cleanup work in nilfs_segctor_destroy(). | ["https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd","https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0","https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b","https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830","https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a","https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b","https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f","https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e","https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb","https://git.kernel.org/stable/c/06afce714d87c7cd1dcfccbcd800c5c5d2cf1cfd","https://git.kernel.org/stable/c/1c3844c5f4eac043954ebf6403fa9fd1f0e9c1c0","https://git.kernel.org/stable/c/6e5c8e8e024e147b834f56f2115aad241433679b","https://git.kernel.org/stable/c/911d38be151921a5d152bb55e81fd752384c6830","https://git.kernel.org/stable/c/a8799662fed1f8747edae87a1937549288baca6a","https://git.kernel.org/stable/c/bc9cee50a4a4ca23bdc49f75ea8242d8a2193b3b","https://git.kernel.org/stable/c/c516db6ab9eabbedbc430b4f93b0d8728e9b427f","https://git.kernel.org/stable/c/eb85dace897c5986bc2f36b3c783c6abb8a4292e","https://git.kernel.org/stable/c/eff7cdf890b02596b8d73e910bdbdd489175dbdb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26594 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid. | ["https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e","https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9","https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d","https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a","https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b","https://git.kernel.org/stable/c/5e6dfec95833edc54c48605a98365a7325e5541e","https://git.kernel.org/stable/c/6eb8015492bcc84e40646390e50a862b2c0529c9","https://git.kernel.org/stable/c/92e470163d96df8db6c4fa0f484e4a229edb903d","https://git.kernel.org/stable/c/a2b21ef1ea4cf632d19b3a7cc4d4245b8e63202a","https://git.kernel.org/stable/c/dd1de9268745f0eac83a430db7afc32cbd62e84b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38541 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: of: module: add buffer overflow check in of_modalias() In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char). | ["https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6","https://git.kernel.org/stable/c/5d59fd637a8af42b211a92b2edb2474325b4d488","https://git.kernel.org/stable/c/c7f24b7d94549ff4623e8f41ea4d9f5319bd8ac8","https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252","https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a","https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e","https://git.kernel.org/stable/c/0b0d5701a8bf02f8fee037e81aacf6746558bfd6","https://git.kernel.org/stable/c/cf7385cb26ac4f0ee6c7385960525ad534323252","https://git.kernel.org/stable/c/e45b69360a63165377b30db4a1dfddd89ca18e9a","https://git.kernel.org/stable/c/ee332023adfd5882808f2dabf037b32d6ce36f9e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2602 | High | N/A | io_uring UAF, Unix SCM garbage collection | ["http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602","https://ubuntu.com/security/notices/USN-5691-1","https://ubuntu.com/security/notices/USN-5692-1","https://ubuntu.com/security/notices/USN-5693-1","https://ubuntu.com/security/notices/USN-5700-1","https://ubuntu.com/security/notices/USN-5752-1","http://packetstormsecurity.com/files/176533/Linux-Broken-Unix-GC-Interaction-Use-After-Free.html","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2602","https://ubuntu.com/security/notices/USN-5691-1","https://ubuntu.com/security/notices/USN-5692-1","https://ubuntu.com/security/notices/USN-5693-1","https://ubuntu.com/security/notices/USN-5700-1","https://ubuntu.com/security/notices/USN-5752-1"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-23222 | High | fixed |
|
kernel/bpf/verifier.c in the Linux kernel through 5.15.14 allows local users to gain privileges because of the availability of pointer arithmetic via certain *_OR_NULL pointer types. | ["http://www.openwall.com/lists/oss-security/2022/01/14/1","http://www.openwall.com/lists/oss-security/2022/01/18/2","http://www.openwall.com/lists/oss-security/2022/06/01/1","http://www.openwall.com/lists/oss-security/2022/06/04/3","http://www.openwall.com/lists/oss-security/2022/06/07/3","https://bugzilla.suse.com/show_bug.cgi?id=1194765","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/","https://security.netapp.com/advisory/ntap-20220217-0002/","https://www.debian.org/security/2022/dsa-5050","https://www.openwall.com/lists/oss-security/2022/01/13/1","http://www.openwall.com/lists/oss-security/2022/01/14/1","http://www.openwall.com/lists/oss-security/2022/01/18/2","http://www.openwall.com/lists/oss-security/2022/06/01/1","http://www.openwall.com/lists/oss-security/2022/06/04/3","http://www.openwall.com/lists/oss-security/2022/06/07/3","https://bugzilla.suse.com/show_bug.cgi?id=1194765","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=64620e0a1e712a778095bd35cbb277dc2259281f","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/FCR3LIRUEXR7CA63W5M2HT3K63MZGKBR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/Z5VTIZZUPC73IEJNZX66BY2YCBRZAELB/","https://security.netapp.com/advisory/ntap-20220217-0002/","https://www.debian.org/security/2022/dsa-5050","https://www.openwall.com/lists/oss-security/2022/01/13/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44947 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fuse: Initialize beyond-EOF page contents before setting uptodate fuse_notify_store(), unlike fuse_do_readpage(), does not enable page zeroing (because it can be used to change partial page contents). So fuse_notify_store() must be more careful to fully initialize page contents (including parts of the page that are beyond end-of-file) before marking the page uptodate. The current code can leave beyond-EOF page contents uninitialized, which makes these uninitialized page contents visible to userspace via mmap(). This is an information leak, but only affects systems which do not enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the corresponding kernel command line parameter). | ["https://git.kernel.org/stable/c/18a067240817bee8a9360539af5d79a4bf5398a5","https://git.kernel.org/stable/c/33168db352c7b56ae18aa55c2cae1a1c5905d30e","https://git.kernel.org/stable/c/3c0da3d163eb32f1f91891efaade027fa9b245b9","https://git.kernel.org/stable/c/4690e2171f651e2b415e3941ce17f2f7b813aff6","https://git.kernel.org/stable/c/49934861514d36d0995be8e81bb3312a499d8d9a","https://git.kernel.org/stable/c/831433527773e665bdb635ab5783d0b95d1246f4","https://git.kernel.org/stable/c/8c78303eafbf85a728dd84d1750e89240c677dd9","https://git.kernel.org/stable/c/ac42e0f0eb66af966015ee33fd355bc6f5d80cd6","https://project-zero.issues.chromium.org/issues/42451729"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2008 | High | fixed |
|
A flaw was found in the Linux kernel's udmabuf device driver. The specific flaw exists within a fault handler. The issue results from the lack of proper validation of user-supplied data, which can result in a memory access past the end of an array. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of the kernel. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2186862","https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4","https://security.netapp.com/advisory/ntap-20230517-0007/","https://www.zerodayinitiative.com/advisories/ZDI-23-441/","https://bugzilla.redhat.com/show_bug.cgi?id=2186862","https://github.com/torvalds/linux/commit/05b252cccb2e5c3f56119d25de684b4f810ba4","https://security.netapp.com/advisory/ntap-20230517-0007/","https://www.zerodayinitiative.com/advisories/ZDI-23-441/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27028 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: spi-mt65xx: Fix NULL pointer access in interrupt handler The TX buffer in spi_transfer can be a NULL pointer, so the interrupt handler may end up writing to the invalid memory and cause crashes. Add a check to trans->tx_buf before using it. | ["https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713","https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38","https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6","https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753","https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4","https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55","https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11","https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4","https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62","https://git.kernel.org/stable/c/1784053cf10a14c4ebd8a890bad5cfe1bee51713","https://git.kernel.org/stable/c/2342b05ec5342a519e00524a507f7a6ea6791a38","https://git.kernel.org/stable/c/55f8ea6731aa64871ee6aef7dba53ee9f9f3b2f6","https://git.kernel.org/stable/c/62b1f837b15cf3ec2835724bdf8577e47d14c753","https://git.kernel.org/stable/c/766ec94cc57492eab97cbbf1595bd516ab0cb0e4","https://git.kernel.org/stable/c/a20ad45008a7c82f1184dc6dee280096009ece55","https://git.kernel.org/stable/c/bcfcdf19698024565eff427706ebbd8df65abd11","https://git.kernel.org/stable/c/bea82355df9e1c299625405b1947fc9b26b4c6d4","https://git.kernel.org/stable/c/c10fed329c1c104f375a75ed97ea3abef0786d62","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4379 | High | fixed |
|
A use-after-free vulnerability was found in __nfs42_ssc_open() in fs/nfs/nfs4file.c in the Linux kernel. This flaw allows an attacker to conduct a remote denial | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/","https://seclists.org/oss-sec/2022/q4/185","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=75333d48f92256a0dec91dbf07835e804fc411c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aeba12b26c79fc35e07e511f692a8907037d95da","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LECFVUHKIRBV5JJBE3KQCLGKNYJPBRCN/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RAVD6JIILAVSRHZ4VXSV3RAAGUXKVXZA/","https://seclists.org/oss-sec/2022/q4/185","https://security.netapp.com/advisory/ntap-20230223-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32233 | High | fixed |
|
In the Linux kernel through 6.3.1, a use-after-free in Netfilter nf_tables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled. | ["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://www.openwall.com/lists/oss-security/2023/05/15/5","https://bugzilla.redhat.com/show_bug.cgi?id=2196105","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab","https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://news.ycombinator.com/item?id=35879660","https://security.netapp.com/advisory/ntap-20230616-0002/","https://www.debian.org/security/2023/dsa-5402","https://www.openwall.com/lists/oss-security/2023/05/08/4","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://www.openwall.com/lists/oss-security/2023/05/15/5","https://bugzilla.redhat.com/show_bug.cgi?id=2196105","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c1592a89942e9678f7d9c8030efa777c0d57edab","https://github.com/torvalds/linux/commit/c1592a89942e9678f7d9c8030efa777c0d57edab","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://news.ycombinator.com/item?id=35879660","https://security.netapp.com/advisory/ntap-20230616-0002/","https://www.debian.org/security/2023/dsa-5402","https://www.openwall.com/lists/oss-security/2023/05/08/4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-27666 | High | fixed |
|
A heap buffer overflow flaw was found in IPsec ESP transformation code in net/ipv4/esp4.c and net/ipv6/esp6.c. This flaw allows a local attacker with a normal user privilege to overwrite kernel heap objects and may cause a local privilege escalation threat. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2061633","https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645","https://security.netapp.com/advisory/ntap-20220429-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2061633","https://github.com/torvalds/linux/commit/ebe48d368e97d007bfeb76fcb065d6cfc4c96645","https://security.netapp.com/advisory/ntap-20220429-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2008-4609 | High | N/A | The TCP implementation in (1) Linux, (2) platforms based on BSD Unix, (3) Microsoft Windows, (4) Cisco products, and probably other operating systems allows remote attackers to cause a denial of service (connection queue exhaustion) via multiple vectors that manipulate information in the TCP state table, as demonstrated by sockstress. | ["http://blog.robertlee.name/2008/10/conjecture-speculation.html","http://insecure.org/stf/tcp-dos-attack-explained.html","http://lists.immunitysec.com/pipermail/dailydave/2008-October/005360.html","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://searchsecurity.techtarget.com.au/articles/27154-TCP-is-fundamentally-borked","http://www.cisco.com/en/US/products/products_security_advisory09186a0080af511d.shtml","http://www.cisco.com/en/US/products/products_security_response09186a0080a15120.html","http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf","http://www.mandriva.com/security/advisories?name=MDVSA-2013:150","http://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html","http://www.outpost24.com/news/news-2008-10-02.html","http://www.us-cert.gov/cas/techalerts/TA09-251A.html","https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-048","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6340","https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html","http://blog.robertlee.name/2008/10/conjecture-speculation.html","http://insecure.org/stf/tcp-dos-attack-explained.html","http://lists.immunitysec.com/pipermail/dailydave/2008-October/005360.html","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://marc.info/?l=bugtraq\u0026m=125856010926699\u0026w=2","http://searchsecurity.techtarget.com.au/articles/27154-TCP-is-fundamentally-borked","http://www.cisco.com/en/US/products/products_security_advisory09186a0080af511d.shtml","http://www.cisco.com/en/US/products/products_security_response09186a0080a15120.html","http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf","http://www.mandriva.com/security/advisories?name=MDVSA-2013:150","http://www.oracle.com/technetwork/topics/security/cpujul2012-392727.html","http://www.outpost24.com/news/news-2008-10-02.html","http://www.us-cert.gov/cas/techalerts/TA09-251A.html","https://docs.microsoft.com/en-us/security-updates/securitybulletins/2009/ms09-048","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6340","https://www.cert.fi/haavoittuvuudet/2008/tcp-vulnerabilities.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52798 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix dfs radar event locking The ath11k active pdevs are protected by RCU but the DFS radar event handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. | ["https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822","https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5","https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e","https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82","https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec","https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10","https://git.kernel.org/stable/c/1fd878e1750190a612b5de2af357cca422ec0822","https://git.kernel.org/stable/c/21ebb0aba580d347e12f01ce5f6e75044427b3d5","https://git.kernel.org/stable/c/3b6c14833165f689cc5928574ebafe52bbce5f1e","https://git.kernel.org/stable/c/426e718ce9ba60013364a54233feee309356cb82","https://git.kernel.org/stable/c/ca420ac4f9451f22347bae44b18ab47ba2c267ec","https://git.kernel.org/stable/c/f882f51905517575c9f793a3dff567af90ef9a10"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47659 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. | ["https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9","https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c","https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3ff0db550","https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff","https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671","https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670","https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f","https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50251 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed. | ["https://git.kernel.org/stable/c/0ab3be58b45b996764aba0187b46de19b3e58a72","https://git.kernel.org/stable/c/a661ed364ae6ae88c2fafa9ddc27df1af2a73701","https://git.kernel.org/stable/c/ac7df3fc80fc82bcc3b1e8f6ebc0d2c435d0c534","https://git.kernel.org/stable/c/b1d2de8a669fa14c499a385e056944d5352b3b40","https://git.kernel.org/stable/c/c43e0ea848e7b9bef7a682cbc5608022d6d29d7b","https://git.kernel.org/stable/c/d3217323525f7596427124359e76ea0d8fcc9874","https://git.kernel.org/stable/c/d5953d680f7e96208c29ce4139a0e38de87a57fe","https://git.kernel.org/stable/c/e3e608cbad376674d19a71ccd0d41804d9393f02","https://github.com/slavin-ayu/CVE-2024-50251-PoC"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38573 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cppc_cpufreq: Fix possible null pointer dereference cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5","https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618","https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf","https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe","https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4","https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c","https://git.kernel.org/stable/c/769c4f355b7962895205b86ad35617873feef9a5","https://git.kernel.org/stable/c/9a185cc5a79ba408e1c73375706630662304f618","https://git.kernel.org/stable/c/b18daa4ec727c0266de5bfc78e818d168cc4aedf","https://git.kernel.org/stable/c/cf7de25878a1f4508c69dc9f6819c21ba177dbfe","https://git.kernel.org/stable/c/dfec15222529d22b15e5b0d63572a9e39570cab4","https://git.kernel.org/stable/c/f84b9b25d045e67a7eee5e73f21278c8ab06713c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2017-6264 | High | N/A | An elevation of privilege vulnerability exists in the NVIDIA GPU driver (gm20b_clk_throt_set_cdev_state), where an out of bound memory read is used as a function pointer could lead to code execution in the kernel.This issue is rated as high because it could allow a local malicious application to execute arbitrary code within the context of a privileged process. Product: Android. Version: N/A. Android ID: A-34705430. References: N-CVE-2017-6264. | ["http://www.securityfocus.com/bid/101744","https://source.android.com/security/bulletin/2017-11-01","http://www.securityfocus.com/bid/101744","https://source.android.com/security/bulletin/2017-11-01"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak during rehash The rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters. If the migration fails, the code tries to migrate the filters back to the old region. However, the rollback itself can also fail in which case another migration will be erroneously performed. Besides the fact that this ping pong is not a very good idea, it also creates a problem. Each virtual chunk references two chunks: The currently used one ('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the first holds the chunk we want to migrate filters to and the second holds the chunk we are migrating filters from. The code currently assumes - but does not verify - that the backup chunk does not exist (NULL) if the currently used chunk does not reference the target region. This assumption breaks when we are trying to rollback a rollback, resulting in the backup chunk being overwritten and leaked [1]. Fix by not rolling back a failed rollback and add a warning to avoid future cases. [1] WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20 Modules linked in: CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:parman_destroy+0x17/0x20 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> | ["https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf","https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e","https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1","https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977","https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d","https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76","https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76","https://git.kernel.org/stable/c/0ae8ff7b6d42e33943af462910bdcfa2ec0cb8cf","https://git.kernel.org/stable/c/413a01886c3958d4b8aac23a3bff3d430b92093e","https://git.kernel.org/stable/c/617e98ba4c50f4547c9eb0946b1cfc26937d70d1","https://git.kernel.org/stable/c/8ca3f7a7b61393804c46f170743c3b839df13977","https://git.kernel.org/stable/c/b3fd51f684a0711504f82de510da109ae639722d","https://git.kernel.org/stable/c/b822644fd90992ee362c5e0c8d2556efc8856c76","https://git.kernel.org/stable/c/c6f3fa7f5a748bf6e5c4eb742686d6952f854e76","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1012 | High | fixed |
|
A memory leak problem was found in the TCP source port generation algorithm in net/ipv4/tcp.c due to the small table perturb size. This flaw may allow an attacker to information leak and may cause a denial of service problem. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2064604","https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/","https://security.netapp.com/advisory/ntap-20221020-0006/","https://bugzilla.redhat.com/show_bug.cgi?id=2064604","https://lore.kernel.org/lkml/20220427065233.2075-1-w%401wt.eu/T/","https://security.netapp.com/advisory/ntap-20221020-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0179 | High | fixed |
|
A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution. | ["http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2161713","https://seclists.org/oss-sec/2023/q1/20","https://security.netapp.com/advisory/ntap-20230511-0003/","http://packetstormsecurity.com/files/171601/Kernel-Live-Patch-Security-Notice-LNS-0093-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2161713","https://seclists.org/oss-sec/2023/q1/20","https://security.netapp.com/advisory/ntap-20230511-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3864 | High | N/A | A flaw was found in the way the dumpable flag setting was handled when certain SUID binaries executed its descendants. The prerequisite is a SUID binary that sets real UID equal to effective UID, and real GID equal to effective GID. The descendant will then have a dumpable value set to 1. As a result, if the descendant process crashes and core_pattern is set to a relative value, its core dump is stored in the current directory with uid:gid permissions. An unprivileged local user with eligible root SUID binary could use this flaw to place core dumps into root-owned directories, potentially resulting in escalation of privileges. | ["https://access.redhat.com/security/cve/CVE-2021-3864","https://bugzilla.redhat.com/show_bug.cgi?id=2015046","https://lore.kernel.org/all/20211221021744.864115-1-longman%40redhat.com/","https://lore.kernel.org/all/20211226150310.GA992%401wt.eu/","https://lore.kernel.org/lkml/20211228170910.623156-1-wander%40redhat.com/","https://security-tracker.debian.org/tracker/CVE-2021-3864","https://www.openwall.com/lists/oss-security/2021/10/20/2","https://access.redhat.com/security/cve/CVE-2021-3864","https://bugzilla.redhat.com/show_bug.cgi?id=2015046","https://lore.kernel.org/all/20211221021744.864115-1-longman%40redhat.com/","https://lore.kernel.org/all/20211226150310.GA992%401wt.eu/","https://lore.kernel.org/lkml/20211228170910.623156-1-wander%40redhat.com/","https://security-tracker.debian.org/tracker/CVE-2021-3864","https://www.openwall.com/lists/oss-security/2021/10/20/2"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35835 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a double-free in arfs_create_groups When `in` allocated by kvzalloc fails, arfs_create_groups will free ft->g and return an error. However, arfs_create_table, the only caller of arfs_create_groups, will hold this error and call to mlx5e_destroy_flow_table, in which the ft->g will be freed again. | ["https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7","https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b","https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb","https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b","https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7","https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056","https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5","https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629","https://git.kernel.org/stable/c/2501afe6c4c9829d03abe9a368b83d9ea1b611b7","https://git.kernel.org/stable/c/3c6d5189246f590e4e1f167991558bdb72a4738b","https://git.kernel.org/stable/c/42876db001bbea7558e8676d1019f08f9390addb","https://git.kernel.org/stable/c/66cc521a739ccd5da057a1cb3d6346c6d0e7619b","https://git.kernel.org/stable/c/b21db3f1ab7967a81d6bbd328d28fe5a4c07a8a7","https://git.kernel.org/stable/c/c57ca114eb00e03274dd38108d07a3750fa3c056","https://git.kernel.org/stable/c/cf116d9c3c2aebd653c2dfab5b10c278e9ec3ee5","https://git.kernel.org/stable/c/e3d3ed8c152971dbe64c92c9ecb98fdb52abb629","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47685 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated--- | ["https://git.kernel.org/stable/c/10210658f827ad45061581cbfc05924b723e8922","https://git.kernel.org/stable/c/7a7b5a27c53b55e91eecf646d1b204e73fa4af93","https://git.kernel.org/stable/c/7bcbc4cda777d26c88500d973fad0d497fc8a82e","https://git.kernel.org/stable/c/7ea2bcfd9bf4c3dbbf22546162226fd1c14d8ad2","https://git.kernel.org/stable/c/872eca64c3267dbc5836b715716fc6c03a18eda7","https://git.kernel.org/stable/c/9c778fe48d20ef362047e3376dee56d77f8500d4","https://git.kernel.org/stable/c/af4b8a704f26f38310655bad67fd8096293275a2","https://git.kernel.org/stable/c/dcf48ab3ca2c55b09c8f9c8de0df01c1943bc4e5","https://git.kernel.org/stable/c/fbff87d682e57ddbbe82abf6d0a1a4a36a98afcd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45934 | High | fixed |
|
An issue was discovered in the Linux kernel through 6.0.10. l2cap_config_req in net/bluetooth/l2cap_core.c has an integer wraparound via L2CAP_CONF_REQ packets. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/","https://security.netapp.com/advisory/ntap-20230113-0008/","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=ae4569813a6e931258db627cdfe50dfb4f917d5d","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/NDAKCGDW6CQ6G3RZWYZJO454R3L5CTQB/","https://security.netapp.com/advisory/ntap-20230113-0008/","https://www.debian.org/security/2023/dsa-5324"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36912 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Track decrypted status in vmbus_gpadl In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. In order to make sure callers of vmbus_establish_gpadl() and vmbus_teardown_gpadl() don't return decrypted/shared pages to allocators, add a field in struct vmbus_gpadl to keep track of the decryption status of the buffers. This will allow the callers to know if they should free or leak the pages. | ["https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81","https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca","https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8","https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99","https://git.kernel.org/stable/c/1999644d95194d4a58d3e80ad04ce19220a01a81","https://git.kernel.org/stable/c/211f514ebf1ef5de37b1cf6df9d28a56cfd242ca","https://git.kernel.org/stable/c/8e62341f5c45b27519b7d193bcc32ada416ad9d8","https://git.kernel.org/stable/c/bfae56be077ba14311509e70706a13458f87ea99"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-32981 | High | N/A | An issue was discovered in the Linux kernel through 5.18.3 on powerpc 32-bit platforms. There is a buffer overflow in ptrace PEEKUSER and POKEUSER (aka PEEKUSR and POKEUSR) when accessing floating point registers. | ["http://www.openwall.com/lists/oss-security/2022/06/14/3","https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e1278444446fc97778a5e5c99bca1ce0bbc5ec9","http://www.openwall.com/lists/oss-security/2022/06/14/3","https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?id=8e1278444446fc97778a5e5c99bca1ce0bbc5ec9"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2002 | Medium | fixed |
|
A vulnerability was found in the HCI sockets implementation due to a missing capability check in net/bluetooth/hci_sock.c in the Linux Kernel. This flaw allows an attacker to unauthorized execution of management commands, compromising the confidentiality, integrity, and availability of Bluetooth communication. | ["https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0004/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/04/16/3","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0004/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/04/16/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52735 | Critical | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself sock_map proto callbacks should never call themselves by design. Protect against bugs like [1] and break out of the recursive loop to avoid a stack overflow in favor of a resource leak. [1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/ | ["https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9","https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49","https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba","https://git.kernel.org/stable/c/5b4a79ba65a1ab479903fff2e604865d229b70a9","https://git.kernel.org/stable/c/7499859881488da97589f3c79cc66fa75748ad49","https://git.kernel.org/stable/c/f312367f5246e04df564d341044286e9e37a97ba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0210 | High | fixed |
|
A bug affects the Linux kernel’s ksmbd NTLMv2 authentication and is known to crash the OS immediately in Linux-based systems. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707","https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6","https://security.netapp.com/advisory/ntap-20230517-0002/","https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/","https://www.openwall.com/lists/oss-security/2023/01/04/1","https://www.openwall.com/lists/oss-security/2023/01/11/1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=797805d81baa814f76cf7bdab35f86408a79d707","https://github.com/cifsd-team/ksmbd/commit/8824b7af409f51f1316e92e9887c2fd48c0b26d6","https://security.netapp.com/advisory/ntap-20230517-0002/","https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/","https://www.openwall.com/lists/oss-security/2023/01/04/1","https://www.openwall.com/lists/oss-security/2023/01/11/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48655 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Harden accesses to the reset domains Accessing reset domains descriptors by the index upon the SCMI drivers requests through the SCMI reset operations interface can potentially lead to out-of-bound violations if the SCMI driver misbehave. Add an internal consistency check before any such domains descriptors accesses. | ["https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de","https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf","https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e","https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268","https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108","https://git.kernel.org/stable/c/1f08a1b26cfc53b7715abc46857c6023bb1b87de","https://git.kernel.org/stable/c/7184491fc515f391afba23d0e9b690caaea72daf","https://git.kernel.org/stable/c/8e65edf0d37698f7a6cb174608d3ec7976baf49e","https://git.kernel.org/stable/c/e9076ffbcaed5da6c182b144ef9f6e24554af268","https://git.kernel.org/stable/c/f2277d9e2a0d092c13bae7ee82d75432bb8b5108","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42896 | High | fixed |
|
There are use-after-free vulnerabilities in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_connect and l2cap_le_connect_req functions which may allow code execution and leaking kernel memory (respectively) remotely via Bluetooth. A remote attacker could execute code leaking kernel memory via Bluetooth if within proximity of the victim. We recommend upgrading past commit https://www.google.com/url https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4 https://www.google.com/url | ["https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4","https://kernel.dance/#711f8c3fb3db61897080468586b970c87c61d9e4","https://github.com/torvalds/linux/commit/711f8c3fb3db61897080468586b970c87c61d9e4","https://kernel.dance/#711f8c3fb3db61897080468586b970c87c61d9e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3594 | Medium | fixed |
|
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function intr_callback of the file drivers/net/usb/r8152.c of the component BPF. The manipulation leads to logging of excessive data. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211363. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211363","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211363"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47941 | High | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c omits a kfree call in certain smb2_handle_negotiate error conditions, aka a memory leak. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917","https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917","https://www.zerodayinitiative.com/advisories/ZDI-22-1687/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=aa7253c2393f6dcd6a1468b0792f6da76edad917","https://github.com/torvalds/linux/commit/aa7253c2393f6dcd6a1468b0792f6da76edad917","https://www.zerodayinitiative.com/advisories/ZDI-22-1687/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2585 | High | fixed |
|
It was discovered that when exec'ing from a non-leader thread, armed POSIX CPU timers would be left on a list but freed, leading to a use-after-free. | ["https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585","https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://www.openwall.com/lists/oss-security/2022/08/09/7","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-2585","https://lore.kernel.org/lkml/20220809170751.164716-1-cascardo@canonical.com/T/#u","https://ubuntu.com/security/notices/USN-5564-1","https://ubuntu.com/security/notices/USN-5565-1","https://ubuntu.com/security/notices/USN-5566-1","https://ubuntu.com/security/notices/USN-5567-1","https://www.openwall.com/lists/oss-security/2022/08/09/7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47726 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode. | ["https://git.kernel.org/stable/c/3aa5254d80969cb576601fb9fec7a188cc8dc169","https://git.kernel.org/stable/c/7be13b73409b553d9d9a6cbb042b4d19e2631cc7","https://git.kernel.org/stable/c/96cfeb0389530ae32ade8a48ae3ae1ac3b6c009d","https://git.kernel.org/stable/c/c2a7fc514637f640ff55c3f3e3ed879970814a3f","https://git.kernel.org/stable/c/e3db757ff9b7101ae68650ac5f6dd5743b68164e","https://git.kernel.org/stable/c/f81302decd64245bb1bd154ecae0f65a9ee21f04"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26804 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. | ["https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b","https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee","https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f","https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9","https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96","https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282","https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383","https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b","https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee","https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f","https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9","https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96","https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282","https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36913 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Leak pages if set_memory_encrypted() fails In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. VMBus code could free decrypted pages if set_memory_encrypted()/decrypted() fails. Leak the pages if this happens. | ["https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a","https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6","https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f","https://git.kernel.org/stable/c/03f5a999adba062456c8c818a683beb1b498983a","https://git.kernel.org/stable/c/6123a4e8e25bd40cf44db14694abac00e6b664e6","https://git.kernel.org/stable/c/e813a0fc2e597146e9cebea61ced9c796d4e308f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-29968 | High | N/A | An issue was discovered in the Linux kernel through 5.17.5. io_rw_init_file in fs/io_uring.c lacks initialization of kiocb->private. | ["https://github.com/torvalds/linux/commit/32452a3eb8b64e01e2be717f518c0be046975b9d","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LU7MT7BPTA2NG24BTLZF5ZWYTLSO7BU3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TLWTG3TWIMLNQEVTA3ZQYVLLU2AJM3DY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XA7UZ3HS73KXVYCIKN5ZDH7LLLGPUMOZ/","https://security.netapp.com/advisory/ntap-20220715-0009/","https://github.com/torvalds/linux/commit/32452a3eb8b64e01e2be717f518c0be046975b9d","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LU7MT7BPTA2NG24BTLZF5ZWYTLSO7BU3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TLWTG3TWIMLNQEVTA3ZQYVLLU2AJM3DY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XA7UZ3HS73KXVYCIKN5ZDH7LLLGPUMOZ/","https://security.netapp.com/advisory/ntap-20220715-0009/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44946 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kcm: Serialise kcm_sendmsg() for the same socket. syzkaller reported UAF in kcm_release(). [0] The scenario is 1. Thread A builds a skb with MSG_MORE and sets kcm->seq_skb. 2. Thread A resumes building skb from kcm->seq_skb but is blocked by sk_stream_wait_memory() 3. Thread B calls sendmsg() concurrently, finishes building kcm->seq_skb and puts the skb to the write queue 4. Thread A faces an error and finally frees skb that is already in the write queue 5. kcm_release() does double-free the skb in the write queue When a thread is building a MSG_MORE skb, another thread must not touch it. Let's add a per-sk mutex and serialise kcm_sendmsg(). [0]: BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline] BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline] BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167 CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G B 6.8.0-rc5-syzkaller-g9abbc24128bc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x178/0x518 mm/kasan/report.c:488 kasan_report+0xd8/0x138 mm/kasan/report.c:601 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381 __skb_unlink include/linux/skbuff.h:2366 [inline] __skb_dequeue include/linux/skbuff.h:2385 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline] __skb_queue_purge include/linux/skbuff.h:3181 [inline] kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691 __sock_release net/socket.c:659 [inline] sock_close+0xa4/0x1e8 net/socket.c:1421 __fput+0x30c/0x738 fs/file_table.c:376 ____fput+0x20/0x30 fs/file_table.c:404 task_work_run+0x230/0x2e0 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x618/0x1f64 kernel/exit.c:871 do_group_exit+0x194/0x22c kernel/exit.c:1020 get_signal+0x1500/0x15ec kernel/signal.c:2893 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline] el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Allocated by task 6166: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x74/0x8c mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x204/0x4c0 mm/slub.c:3903 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1296 [inline] kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x220/0x2c0 net/socket.c:768 splice_to_socket+0x7cc/0xd58 fs/splice.c:889 do_splice_from fs/splice.c:941 [inline] direct_splice_actor+0xec/0x1d8 fs/splice.c:1164 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108 do_splice_direct_actor ---truncated--- | ["https://git.kernel.org/stable/c/00425508f30baa5ab6449a1f478480ca7cffa6da","https://git.kernel.org/stable/c/6633b17840bf828921254d788ccd15602843fe9b","https://git.kernel.org/stable/c/72da240aafb142630cf16adc803ccdacb3780849","https://git.kernel.org/stable/c/807067bf014d4a3ae2cc55bd3de16f22a01eb580","https://git.kernel.org/stable/c/8c9cdbf600143bd6835c8b8351e5ac956da79aec","https://git.kernel.org/stable/c/9c8d544ed619f704e2b70e63e08ab75630c2ea23","https://git.kernel.org/stable/c/eb06c8d3022ce6738711191c89f9b3e9cfb91914","https://git.kernel.org/stable/c/fa6c23fe6dcac8c8bd63920ee8681292a2bd544e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35001 | High | fixed |
|
Linux Kernel nftables Out-Of-Bounds Read/Write Vulnerability; nft_byteorder poorly handled vm register contents when CAP_NET_ADMIN is in any user or network namespace | ["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/3","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/","https://security.netapp.com/advisory/ntap-20230824-0007/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/3","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/3","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121515.747251-1-cascardo@canonical.com/T/","https://security.netapp.com/advisory/ntap-20230824-0007/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6546 | High | fixed |
|
A race condition was found in the GSM 0710 tty multiplexor in the Linux kernel. This issue occurs when two threads execute the GSMIOC_SETCONF ioctl on the same tty file descriptor with the gsm line discipline enabled, and can lead to a use-after-free problem on a struct gsm_dlci while restarting the gsm mux. This could allow a local unprivileged user to escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2024:0930","https://access.redhat.com/errata/RHSA-2024:0937","https://access.redhat.com/errata/RHSA-2024:1018","https://access.redhat.com/errata/RHSA-2024:1019","https://access.redhat.com/errata/RHSA-2024:1055","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1607","https://access.redhat.com/errata/RHSA-2024:1612","https://access.redhat.com/errata/RHSA-2024:1614","https://access.redhat.com/errata/RHSA-2024:2093","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2621","https://access.redhat.com/errata/RHSA-2024:2697","https://access.redhat.com/errata/RHSA-2024:4577","https://access.redhat.com/errata/RHSA-2024:4729","https://access.redhat.com/errata/RHSA-2024:4731","https://access.redhat.com/errata/RHSA-2024:4970","https://access.redhat.com/security/cve/CVE-2023-6546","https://bugzilla.redhat.com/show_bug.cgi?id=2255498","https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527","http://www.openwall.com/lists/oss-security/2024/04/10/18","http://www.openwall.com/lists/oss-security/2024/04/10/21","http://www.openwall.com/lists/oss-security/2024/04/11/7","http://www.openwall.com/lists/oss-security/2024/04/11/9","http://www.openwall.com/lists/oss-security/2024/04/12/1","http://www.openwall.com/lists/oss-security/2024/04/12/2","http://www.openwall.com/lists/oss-security/2024/04/16/2","http://www.openwall.com/lists/oss-security/2024/04/17/1","https://access.redhat.com/errata/RHSA-2024:0930","https://access.redhat.com/errata/RHSA-2024:0937","https://access.redhat.com/errata/RHSA-2024:1018","https://access.redhat.com/errata/RHSA-2024:1019","https://access.redhat.com/errata/RHSA-2024:1055","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1607","https://access.redhat.com/errata/RHSA-2024:1612","https://access.redhat.com/errata/RHSA-2024:1614","https://access.redhat.com/errata/RHSA-2024:2093","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2621","https://access.redhat.com/errata/RHSA-2024:2697","https://access.redhat.com/errata/RHSA-2024:4577","https://access.redhat.com/errata/RHSA-2024:4729","https://access.redhat.com/errata/RHSA-2024:4731","https://access.redhat.com/security/cve/CVE-2023-6546","https://bugzilla.redhat.com/show_bug.cgi?id=2255498","https://github.com/torvalds/linux/commit/3c4f8333b582487a2d1e02171f1465531cde53e3","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20527"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47938 | Medium | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2misc.c has an out-of-bounds read and OOPS for SMB2_TREE_CONNECT. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e","https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e","https://www.zerodayinitiative.com/advisories/ZDI-22-1689/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=824d4f64c20093275f72fc8101394d75ff6a249e","https://github.com/torvalds/linux/commit/824d4f64c20093275f72fc8101394d75ff6a249e","https://www.zerodayinitiative.com/advisories/ZDI-22-1689/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26952 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix potencial out-of-bounds when buffer offset is invalid I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length. | ["https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5","https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63","https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e","https://git.kernel.org/stable/c/480469f145e5abf83361e608734e421b7d99693d","https://git.kernel.org/stable/c/ad6480c9a5d884e2704adc51d69895d93339176c","https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da","https://git.kernel.org/stable/c/0c5541b4c980626fa3cab16ba1a451757778bbb5","https://git.kernel.org/stable/c/2dcda336b6e80b72d58d30d40f2fad9724e5fe63","https://git.kernel.org/stable/c/39bdc4197acf2ed13269167ccf093ee28cfa2a4e","https://git.kernel.org/stable/c/c6cd2e8d2d9aa7ee35b1fa6a668e32a22a9753da"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0045 | High | fixed |
|
The current implementation of the prctl syscall does not issue an IBPB immediately during the syscall. The ib_prctl_set function updates the Thread Information Flags (TIFs) for the task and updates the SPEC_CTRL MSR on the function __speculation_ctrl_update, but the IBPB is only issued on the next schedule, when the TIF bits are checked. This leaves the victim vulnerable to values already injected on the BTB, prior to the prctl syscall. The patch that added the support for the conditional mitigation via prctl (ib_prctl_set) dates back to the kernel 4.9.176. We recommend upgrading past commit a664ec9158eeddd75121d39c9a0758016097fa96 | ["https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96","https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230714-0001/","https://git.kernel.org/tip/a664ec9158eeddd75121d39c9a0758016097fa96","https://github.com/google/security-research/security/advisories/GHSA-9x5g-vmxf-4qj8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230714-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-31248 | High | fixed |
|
Linux Kernel nftables Use-After-Free Local Privilege Escalation Vulnerability; `nft_chain_lookup_byid()` failed to check whether a chain was active and CAP_NET_ADMIN is in any user or network namespace | ["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/2","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/","https://security.netapp.com/advisory/ntap-20240201-0001/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/2","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/07/05/2","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGZC5XOANA75OJ4XARBBXYSLDKUIJI5E/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPHI46ROSSLVAV4R5LJWJYU747JGOS6D/","https://lore.kernel.org/netfilter-devel/20230705121627.GC19489@breakpoint.cc/T/","https://security.netapp.com/advisory/ntap-20240201-0001/","https://www.debian.org/security/2023/dsa-5453","https://www.openwall.com/lists/oss-security/2023/07/05/2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41218 | Medium | N/A | In drivers/media/dvb-core/dmxdev.c in the Linux kernel through 5.19.10, there is a use-after-free caused by refcount races, affecting dvb_demux_open and dvb_dmxdev_release. | ["http://www.openwall.com/lists/oss-security/2022/09/23/4","http://www.openwall.com/lists/oss-security/2022/09/24/1","http://www.openwall.com/lists/oss-security/2022/09/24/2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/","https://www.debian.org/security/2023/dsa-5324","http://www.openwall.com/lists/oss-security/2022/09/23/4","http://www.openwall.com/lists/oss-security/2022/09/24/1","http://www.openwall.com/lists/oss-security/2022/09/24/2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fd3d91ab1c6ab0628fe642dd570b56302c30a792","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/media/dvb-core/dmxdev.c","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20220908132754.30532-1-tiwai%40suse.de/","https://www.debian.org/security/2023/dsa-5324"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: icmp: prevent possible NULL dereferences from icmp_build_probe() First problem is a double call to __in_dev_get_rcu(), because the second one could return NULL. if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list) Second problem is a read from dev->ip6_ptr with no NULL check: if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list)) Use the correct RCU API to fix these. v2: add missing include <net/addrconf.h> | ["https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401","https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767","https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270","https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941","https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350","https://git.kernel.org/stable/c/23b7ee4a8d559bf38eac7ce5bb2f6ebf76f9c401","https://git.kernel.org/stable/c/3e2979bf080c40da4f7c93aff8575ab8bc62b767","https://git.kernel.org/stable/c/599c9ad5e1d43f5c12d869f5fd406ba5d8c55270","https://git.kernel.org/stable/c/c58e88d49097bd12dfcfef4f075b43f5d5830941","https://git.kernel.org/stable/c/d68dc711d84fdcf698e5d45308c3ddeede586350"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42703 | Medium | fixed |
|
mm/rmap.c in the Linux kernel before 5.19.7 has a use-after-free related to leaf anon_vma double reuse. | ["https://bugs.chromium.org/p/project-zero/issues/detail?id=2351","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b","https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b","https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2351","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2555283eb40df89945557273121e9393ef9b542b","https://github.com/torvalds/linux/commit/2555283eb40df89945557273121e9393ef9b542b","https://googleprojectzero.blogspot.com/2022/12/exploiting-CVE-2022-42703-bringing-back-the-stack-attack.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50083 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 </IRQ> <TASK> __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated--- | ["https://git.kernel.org/stable/c/229dfdc36f31a8d47433438bc0e6e1662c4ab404","https://git.kernel.org/stable/c/4dabcdf581217e60690467a37c956a5b8dbc6bd9","https://git.kernel.org/stable/c/9729010a0ac5945c1bf6847dd0778d8a1a4b72ac","https://git.kernel.org/stable/c/ba8e65814e519eeb17d086952bce7de93f7a40da","https://git.kernel.org/stable/c/c38add9ac0e4d4f418e6443a688491499021add9","https://git.kernel.org/stable/c/db04d1848777ae52a7ab93c4591e7c0bf8f55fb4","https://security.netapp.com/advisory/ntap-20250523-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42720 | High | fixed |
|
Various refcounting bugs in the multi-BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to trigger use-after-free conditions to potentially execute code. | ["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204059","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204059","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=0b7808818cb9df6680f98996b8e9a439fa7bcc2f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42719 | High | fixed |
|
A use-after-free in the mac80211 stack when parsing a multi-BSSID element in the Linux kernel 5.2 through 5.19.x before 5.19.16 could be used by attackers (able to inject WLAN frames) to crash the kernel and potentially execute code. | ["http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204051","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/171005/Kernel-Live-Patch-Security-Notice-LNS-0091-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204051","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89b922578dac497dcabf57cf771c6","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52699 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sysv: don't call sb_bread() with pointers_lock held syzbot is reporting sleep in atomic context in SysV filesystem [1], for sb_bread() is called with rw_spinlock held. A "write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock" bug and a "sb_bread() with write_lock(&pointers_lock)" bug were introduced by "Replace BKL for chain locking with sysvfs-private rwlock" in Linux 2.5.12. Then, "[PATCH] err1-40: sysvfs locking fix" in Linux 2.6.8 fixed the former bug by moving pointers_lock lock to the callers, but instead introduced a "sb_bread() with read_lock(&pointers_lock)" bug (which made this problem easier to hit). Al Viro suggested that why not to do like get_branch()/get_block()/ find_shared() in Minix filesystem does. And doing like that is almost a revert of "[PATCH] err1-40: sysvfs locking fix" except that get_branch() from with find_shared() is called without write_lock(&pointers_lock). | ["https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76","https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f","https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09","https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1","https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac","https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3","https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e","https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927","https://git.kernel.org/stable/c/13b33feb2ebddc2b1aa607f553566b18a4af1d76","https://git.kernel.org/stable/c/1b4fe801b5bedec2b622ddb18e5c9bf26c63d79f","https://git.kernel.org/stable/c/53cb1e52c9db618c08335984d1ca80db220ccf09","https://git.kernel.org/stable/c/674c1c4229e743070e09db63a23442950ff000d1","https://git.kernel.org/stable/c/89e8524135a3902e7563a5a59b7b5ec1bf4904ac","https://git.kernel.org/stable/c/a69224223746ab96d43e5db9d22d136827b7e2d3","https://git.kernel.org/stable/c/f123dc86388cb669c3d6322702dc441abc35c31e","https://git.kernel.org/stable/c/fd203d2c671bdee9ab77090ff394d3b71b627927","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3646 | Medium | N/A | A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects the function nilfs_attach_log_writer of the file fs/nilfs2/segment.c of the component BPF. The manipulation leads to memory leak. The attack may be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211961 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d51a97063db4704a5ef6bc978dddab1636a306","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211961","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d51a97063db4704a5ef6bc978dddab1636a306","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211961"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6931 | High | fixed |
|
A heap out-of-bounds write vulnerability in the Linux kernel's Performance Events system component can be exploited to achieve local privilege escalation. A perf_event's read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group(). We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b. | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://kernel.dance/382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://kernel.dance/382c27f4ed28f803b1f1473ac2d8db0afc795a1b","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1652 | High | fixed |
|
Linux Kernel could allow a local attacker to execute arbitrary code on the system, caused by a concurrency use-after-free flaw in the bad_flp_intr function. By executing a specially-crafted program, an attacker could exploit this vulnerability to execute arbitrary code or cause a denial of service condition on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=1832397","https://francozappa.github.io/about-bias/","https://kb.cert.org/vuls/id/647177/","https://security.netapp.com/advisory/ntap-20220722-0002/","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=1832397","https://francozappa.github.io/about-bias/","https://kb.cert.org/vuls/id/647177/","https://security.netapp.com/advisory/ntap-20220722-0002/","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3621 | Medium | N/A | A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_bmap_lookup_at_level of the file fs/nilfs2/inode.c of the component nilfs2. The manipulation leads to null pointer dereference. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211920. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=21a87d88c2253350e115029f14fe2a10a7e6c856","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211920","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=21a87d88c2253350e115029f14fe2a10a7e6c856","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211920"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: af_unix: Clear stale u->oob_skb. syzkaller started to report deadlock of unix_gc_lock after commit 4090fa373f0e ("af_unix: Replace garbage collection algorithm."), but it just uncovers the bug that has been there since commit 314001f0bf92 ("af_unix: Add OOB support"). The repro basically does the following. from socket import * from array import array c1, c2 = socketpair(AF_UNIX, SOCK_STREAM) c1.sendmsg([b'a'], [(SOL_SOCKET, SCM_RIGHTS, array("i", [c2.fileno()]))], MSG_OOB) c2.recv(1) # blocked as no normal data in recv queue c2.close() # done async and unblock recv() c1.close() # done async and trigger GC A socket sends its file descriptor to itself as OOB data and tries to receive normal data, but finally recv() fails due to async close(). The problem here is wrong handling of OOB skb in manage_oob(). When recvmsg() is called without MSG_OOB, manage_oob() is called to check if the peeked skb is OOB skb. In such a case, manage_oob() pops it out of the receive queue but does not clear unix_sock(sk)->oob_skb. This is wrong in terms of uAPI. Let's say we send "hello" with MSG_OOB, and "world" without MSG_OOB. The 'o' is handled as OOB data. When recv() is called twice without MSG_OOB, the OOB data should be lost. >>> from socket import * >>> c1, c2 = socketpair(AF_UNIX, SOCK_STREAM, 0) >>> c1.send(b'hello', MSG_OOB) # 'o' is OOB data 5 >>> c1.send(b'world') 5 >>> c2.recv(5) # OOB data is not received b'hell' >>> c2.recv(5) # OOB date is skipped b'world' >>> c2.recv(5, MSG_OOB) # This should return an error b'o' In the same situation, TCP actually returns -EINVAL for the last recv(). Also, if we do not clear unix_sk(sk)->oob_skb, unix_poll() always set EPOLLPRI even though the data has passed through by previous recv(). To avoid these issues, we must clear unix_sk(sk)->oob_skb when dequeuing it from recv queue. The reason why the old GC did not trigger the deadlock is because the old GC relied on the receive queue to detect the loop. When it is triggered, the socket with OOB data is marked as GC candidate because file refcount == inflight count (1). However, after traversing all inflight sockets, the socket still has a positive inflight count (1), thus the socket is excluded from candidates. Then, the old GC lose the chance to garbage-collect the socket. With the old GC, the repro continues to create true garbage that will never be freed nor detected by kmemleak as it's linked to the global inflight list. That's why we couldn't even notice the issue. | ["https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6","https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf","https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9","https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e","https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153","https://git.kernel.org/stable/c/601a89ea24d05089debfa2dc896ea9f5937ac7a6","https://git.kernel.org/stable/c/698a95ade1a00e6494482046902b986dfffd1caf","https://git.kernel.org/stable/c/84a352b7eba1142a95441380058985ff19f25ec9","https://git.kernel.org/stable/c/b46f4eaa4f0ec38909fb0072eea3aeddb32f954e","https://git.kernel.org/stable/c/b4bc99d04c689b5652665394ae8d3e02fb754153"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1829 | High | fixed |
|
A use-after-free vulnerability in the Linux Kernel traffic control index filter (tcindex) can be exploited to achieve local privilege escalation. The tcindex_delete function which does not properly deactivate filters in case of a perfect hashes while deleting the underlying structure which can later lead to double freeing the structure. A local attacker user can use this vulnerability to elevate its privileges to root. We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230601-0001/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://kernel.dance/#8c710f75256bb3cf05ac7b1672c82b92c43f3d28","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230601-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-46813 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.5.9, exploitable by local users with userspace access to MMIO registers. Incorrect access checking in the #VC handler and instruction emulation of the SEV-ES emulation of MMIO accesses could lead to arbitrary write access to kernel memory (and thus privilege escalation). This depends on a race condition through which userspace can replace an instruction before the #VC handler reads it. | ["https://bugzilla.suse.com/show_bug.cgi?id=1212649","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://bugzilla.suse.com/show_bug.cgi?id=1212649","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63e44bc52047f182601e7817da969a105aa1f721","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a37cd2a59d0cb270b1bba568fd3a3b8668b9d3ba","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b9cb9c45583b911e0db71d09caa6b56469eb2bdf","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47693 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/1403c8b14765eab805377dd3b75e96ace8747aed","https://git.kernel.org/stable/c/1730d47d1865af89efd01cf0469a9a739cbf60f2","https://git.kernel.org/stable/c/290fe42fe0165205c4451334d8833a9202ae1d52","https://git.kernel.org/stable/c/45f63f4bb9a7128a6209d766c2fc02b3d42fbf3e","https://git.kernel.org/stable/c/af633fd9d9fff59e31c804f47ca0c8a784977773","https://git.kernel.org/stable/c/d08754be993f270e3d296d8f5d8e071fe6638651"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-27815 | High | fixed |
|
A flaw was found in the JFS filesystem code in the Linux Kernel which allows a local attacker with the ability to set extended attributes to panic the system, causing memory corruption or escalating privileges. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. | ["http://www.openwall.com/lists/oss-security/2020/11/30/5","http://www.openwall.com/lists/oss-security/2020/12/28/1","https://bugzilla.redhat.com/show_bug.cgi?id=1897668%2C","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c61b3e4839007668360ed8b87d7da96d2e59fc6c","https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html","https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html","https://security.netapp.com/advisory/ntap-20210702-0004/","https://www.debian.org/security/2021/dsa-4843","https://www.openwall.com/lists/oss-security/2020/11/30/5%2C","https://www.openwall.com/lists/oss-security/2020/12/28/1%2C","http://www.openwall.com/lists/oss-security/2020/11/30/5","http://www.openwall.com/lists/oss-security/2020/12/28/1","https://bugzilla.redhat.com/show_bug.cgi?id=1897668%2C","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c61b3e4839007668360ed8b87d7da96d2e59fc6c","https://lists.debian.org/debian-lts-announce/2021/02/msg00018.html","https://lists.debian.org/debian-lts-announce/2021/03/msg00010.html","https://security.netapp.com/advisory/ntap-20210702-0004/","https://www.debian.org/security/2021/dsa-4843","https://www.openwall.com/lists/oss-security/2020/11/30/5%2C","https://www.openwall.com/lists/oss-security/2020/12/28/1%2C"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47692 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen. | ["https://git.kernel.org/stable/c/0f1d007bbea38a61cf9c5392708dc70ae9d84a3d","https://git.kernel.org/stable/c/1ff8be8d008b9ddc8e7043fbddd37d5d451b271b","https://git.kernel.org/stable/c/22451a16b7ab7debefce660672566be887db1637","https://git.kernel.org/stable/c/318f70857caab3da9a6ada9bc8c1f4f7591b695e","https://git.kernel.org/stable/c/6d07040ae5c2214e39c7444d898039c9e655a79a","https://git.kernel.org/stable/c/766d5fbd78f7a52b3888449a0358760477b74602","https://git.kernel.org/stable/c/84a563d136faf514fdad1ade28d7a142fd313cb8","https://git.kernel.org/stable/c/b7b7a8df41ef18862dd6b22289fb46c2c12398af"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41674 | High | fixed |
|
An issue was discovered in the Linux kernel before 5.19.16. Attackers able to inject WLAN frames could cause a buffer overflow in the ieee80211_bss_info_update function in net/mac80211/scan.c. | ["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","https://bugzilla.suse.com/show_bug.cgi?id=1203770","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/10/13/5","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/2","https://bugzilla.suse.com/show_bug.cgi?id=1203770","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/net/mac80211/scan.c","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=aebe9f4639b13a1f4e9a6b42cdd2e38c617b442d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/10/13/5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49997 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied. | ["https://git.kernel.org/stable/c/1097bf16501ed5e35358d848b0a94ad2830b0f65","https://git.kernel.org/stable/c/185df159843d30fb71f821e7ea4368c2a3bfcd36","https://git.kernel.org/stable/c/2bf4c101d7c99483b8b15a0c8f881e3f399f7e18","https://git.kernel.org/stable/c/431b122933b197820d319eb3987a67d04346ce9e","https://git.kernel.org/stable/c/45c0de18ff2dc9af01236380404bbd6a46502c69","https://git.kernel.org/stable/c/469856f76f4802c5d7e3d20e343185188de1e2db","https://git.kernel.org/stable/c/60c068444c20bf9a3e22b65b5f6f3d9edc852931","https://git.kernel.org/stable/c/905f06a34f960676e7dc77bea00f2f8fe18177ad","https://git.kernel.org/stable/c/e66e38d07b31e177ca430758ed97fbc79f27d966"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47940 | High | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.18 before 5.18.18. fs/ksmbd/smb2pdu.c lacks length validation in the non-padding case in smb2_write. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6","https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.18","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=158a66b245739e15858de42c0ba60fcf3de9b8e6","https://github.com/torvalds/linux/commit/158a66b245739e15858de42c0ba60fcf3de9b8e6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4147 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s Netfilter functionality when adding a rule with NFTA_RULE_CHAIN_ID. This flaw allows a local user to crash or escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/security/cve/CVE-2023-4147","https://bugzilla.redhat.com/show_bug.cgi?id=2225239","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211","https://www.spinics.net/lists/stable/msg671573.html","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/security/cve/CVE-2023-4147","https://bugzilla.redhat.com/show_bug.cgi?id=2225239","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0ebc1064e4874d5987722a2ddbc18f94aa53b211","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20231020-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://www.spinics.net/lists/stable/msg671573.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52766 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix out of bounds access in hci_dma_irq_handler Do not loop over ring headers in hci_dma_irq_handler() that are not allocated and enabled in hci_dma_init(). Otherwise out of bounds access will occur from rings->headers[i] access when i >= number of allocated ring headers. | ["https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574","https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65","https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6","https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b","https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df","https://git.kernel.org/stable/c/45a832f989e520095429589d5b01b0c65da9b574","https://git.kernel.org/stable/c/4c86cb2321bd9c72d3b945ce7f747961beda8e65","https://git.kernel.org/stable/c/7c2b91b30d74d7c407118ad72502d4ca28af1af6","https://git.kernel.org/stable/c/8be39f66915b40d26ea2c18ba84b5c3d5da6809b","https://git.kernel.org/stable/c/d23ad76f240c0f597b7a9eb79905d246f27d40df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36931 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/cio: Ensure the copied buf is NUL terminated Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from userspace to that buffer. Later, we use scanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using scanf. Fix this issue by using memdup_user_nul instead. | ["https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65","https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c","https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2","https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5","https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784","https://git.kernel.org/stable/c/06759ebaf75c19c87b2453a5e130e9e61e9b5d65","https://git.kernel.org/stable/c/10452edd175fcc4fd0f5ac782ed2a002e3e5d65c","https://git.kernel.org/stable/c/84b38f48836662c4bfae646c014f4e981e16a2b2","https://git.kernel.org/stable/c/c9d48ce163305595ae20aee27774192476d5e6a5","https://git.kernel.org/stable/c/da7c622cddd4fe36be69ca61e8c42e43cde94784"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-25265 | High | N/A | In the Linux kernel through 5.16.10, certain binary files may have the exec-all attribute if they were built in approximately 2003 (e.g., with GCC 3.2.2 and Linux kernel 2.4.20). This can cause execution of bytes located in supposedly non-executable regions of a file. | ["https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294","https://github.com/x0reaxeax/exec-prot-bypass","https://security.netapp.com/advisory/ntap-20220318-0005/","https://github.com/torvalds/linux/blob/1c33bb0507508af24fd754dd7123bd8e997fab2f/arch/x86/include/asm/elf.h#L281-L294","https://github.com/x0reaxeax/exec-prot-bypass","https://security.netapp.com/advisory/ntap-20220318-0005/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2078 | Medium | fixed |
|
A vulnerability was found in the Linux kernel's nft_set_desc_concat_parse() function .This flaw allows an attacker to trigger a buffer overflow via nft_set_desc_concat_parse() , causing a denial of service and possibly to run code. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2096178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85","https://www.debian.org/security/2022/dsa-5161","https://bugzilla.redhat.com/show_bug.cgi?id=2096178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/nf_tables_api.c?id=fecf31ee395b0295f2d7260aa29946b7605f7c85","https://www.debian.org/security/2022/dsa-5161"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42225 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: replace skb_put with skb_put_zero Avoid potentially reusing uninitialized data | ["https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657","https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074","https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578","https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2","https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af","https://git.kernel.org/stable/c/22ea2a7f0b64d323625950414a4496520fb33657","https://git.kernel.org/stable/c/64f86337ccfe77fe3be5a9356b0dabde23fbb074","https://git.kernel.org/stable/c/7f819a2f4fbc510e088b49c79addcf1734503578","https://git.kernel.org/stable/c/dc7f14d00d0c4c21898f3504607f4a31079065a2","https://git.kernel.org/stable/c/ff6b26be13032c5fbd6b6a0b24358f8eaac4f3af"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-5717 | High | fixed |
|
A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation. If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer. We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06","https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/events?id=32671e3799ca2e4590773fd0e63aaa4229e50c06","https://kernel.dance/32671e3799ca2e4590773fd0e63aaa4229e50c06","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35878 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: of: module: prevent NULL pointer dereference in vsnprintf() In of_modalias(), we can get passed the str and len parameters which would cause a kernel oops in vsnprintf() since it only allows passing a NULL ptr when the length is also 0. Also, we need to filter out the negative values of the len parameter as these will result in a really huge buffer since snprintf() takes size_t parameter while ours is ssize_t... Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool. | ["https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898","https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987","https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b","https://git.kernel.org/stable/c/544561dc56f7e69a053c25e11e6170f48bb97898","https://git.kernel.org/stable/c/a1aa5390cc912934fee76ce80af5f940452fa987","https://git.kernel.org/stable/c/e4a449368a2ce6d57a775d0ead27fc07f5a86e5b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52755 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab out of bounds write in smb_inherit_dacl() slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size. | ["https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70","https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb","https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa","https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819","https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb","https://git.kernel.org/stable/c/09d9d8b40a3338193619c14ed4dc040f4f119e70","https://git.kernel.org/stable/c/712e01f32e577e7e48ab0adb5fe550646a3d93cb","https://git.kernel.org/stable/c/8387c94d73ec66eb597c7a23a8d9eadf64bfbafa","https://git.kernel.org/stable/c/aaf0a07d60887d6c36fc46a24de0083744f07819","https://git.kernel.org/stable/c/eebff19acaa35820cb09ce2ccb3d21bee2156ffb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3640 | High | N/A | A possible unauthorized memory access flaw was found in the Linux kernel's cpu_entry_area mapping of X86 CPU data to memory, where a user may guess the location of exception stacks or other important data. Based on the previous CVE-2023-0597, the 'Randomize per-cpu entry area' feature was implemented in /arch/x86/mm/cpu_entry_area.c, which works through the init_cea_offsets() function when KASLR is enabled. However, despite this feature, there is still a risk of per-cpu entry area leaks. This issue could allow a local user to gain access to some important data with memory in an expected location and potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3640","https://bugzilla.redhat.com/show_bug.cgi?id=2217523","https://access.redhat.com/security/cve/CVE-2023-3640","https://bugzilla.redhat.com/show_bug.cgi?id=2217523"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39277 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma-mapping: benchmark: handle NUMA_NO_NODE correctly cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark() resulting in the following sanitizer report: UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28 index -1 is out of range for type 'cpumask [64][1]' CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117) ubsan_epilogue (lib/ubsan.c:232) __ubsan_handle_out_of_bounds (lib/ubsan.c:429) cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline] do_map_benchmark (kernel/dma/map_benchmark.c:104) map_benchmark_ioctl (kernel/dma/map_benchmark.c:246) full_proxy_unlocked_ioctl (fs/debugfs/file.c:333) __x64_sys_ioctl (fs/ioctl.c:890) do_syscall_64 (arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Use cpumask_of_node() in place when binding a kernel thread to a cpuset of a particular node. Note that the provided node id is checked inside map_benchmark_ioctl(). It's just a NUMA_NO_NODE case which is not handled properly later. Found by Linux Verification Center (linuxtesting.org). | ["https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f","https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41","https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464","https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13","https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f","https://git.kernel.org/stable/c/50ee21bfc005e69f183d6b4b454e33f0c2571e1f","https://git.kernel.org/stable/c/5a91116b003175302f2e6ad94b76fb9b5a141a41","https://git.kernel.org/stable/c/8e1ba9df9a35e8dc64f657a64e523c79ba01e464","https://git.kernel.org/stable/c/b41b0018e8ca06e985e87220a618ec633988fd13","https://git.kernel.org/stable/c/e64746e74f717961250a155e14c156616fcd981f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32252 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_LOGOFF commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. | ["https://access.redhat.com/security/cve/CVE-2023-32252","https://bugzilla.redhat.com/show_bug.cgi?id=2219815","https://security.netapp.com/advisory/ntap-20231124-0001/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/","https://access.redhat.com/security/cve/CVE-2023-32252","https://bugzilla.redhat.com/show_bug.cgi?id=2219815","https://security.netapp.com/advisory/ntap-20231124-0001/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20590/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2663 | Medium | N/A | An issue was found in the Linux kernel in nf_conntrack_irc where the message handling can be confused and incorrectly matches the message. A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured. | ["https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/netfilter-devel/20220826045658.100360-1-dgl%40dgl.cx/T/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/08/30/1","https://www.youtube.com/watch?v=WIq-YgQuYCA","https://dgl.cx/2022/08/nat-again-irc-cve-2022-2663","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/netfilter-devel/20220826045658.100360-1-dgl%40dgl.cx/T/","https://www.debian.org/security/2022/dsa-5257","https://www.openwall.com/lists/oss-security/2022/08/30/1","https://www.youtube.com/watch?v=WIq-YgQuYCA"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0461 | High | fixed |
|
There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege. There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock. When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable. The setsockopt TCP_ULP operation does not require any privilege. We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c","https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c02d41d71f90a5168391b6a5f2954112ba2307c","https://kernel.dance/#2c02d41d71f90a5168391b6a5f2954112ba2307c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230331-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1011 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s FUSE filesystem in the way a user triggers write(). This flaw allows a local user to gain unauthorized access to data from the FUSE filesystem, resulting in privilege escalation. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2064855","https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=2064855","https://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git/commit/?h=for-next","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://www.oracle.com/security-alerts/cpujul2022.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3526 | High | fixed |
|
A vulnerability classified as problematic was found in Linux Kernel. This vulnerability affects the function macvlan_handle_frame of the file drivers/net/macvlan.c of the component skb. The manipulation leads to memory leak. The attack can be initiated remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211024. | ["https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=e16b859872b87650bb55b12cca5a5fcdc49c1442","https://vuldb.com/?id.211024","https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=e16b859872b87650bb55b12cca5a5fcdc49c1442","https://vuldb.com/?id.211024"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36013 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect() Extend a critical section to prevent chan from early freeing. Also make the l2cap_connect() return type void. Nothing is using the returned value but it is ugly to return a potentially freed pointer. Making it void will help with backports because earlier kernels did use the return value. Now the compile will break for kernels where this patch is not a complete fix. Call stack summary: [use] l2cap_bredr_sig_cmd l2cap_connect ┌ mutex_lock(&conn->chan_lock); │ chan = pchan->ops->new_connection(pchan); <- alloc chan │ __l2cap_chan_add(conn, chan); │ l2cap_chan_hold(chan); │ list_add(&chan->list, &conn->chan_l); ... (1) └ mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free [free] l2cap_conn_del ┌ mutex_lock(&conn->chan_lock); │ foreach chan in conn->chan_l: ... (2) │ l2cap_chan_put(chan); │ l2cap_chan_destroy │ kfree(chan) ... (3) <- chan freed └ mutex_unlock(&conn->chan_lock); ================================================================== BUG: KASAN: slab-use-after-free in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: slab-use-after-free in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0 net/bluetooth/l2cap_core.c:4260 Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311 | ["https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658","https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6","https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/4d7b41c0e43995b0e992b9f8903109275744b658","https://git.kernel.org/stable/c/826af9d2f69567c646ff46d10393d47e30ad23c6","https://git.kernel.org/stable/c/cfe560c7050bfb37b0d2491bbe7cd8b59e77fdc5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1199 | High | N/A | A flaw was found in the Linux kernel. This flaw allows an attacker to crash the Linux kernel by simulating amateur radio from the user space, resulting in a null-ptr-deref vulnerability and a use-after-free vulnerability. | ["https://access.redhat.com/security/cve/CVE-2022-1199","https://bugzilla.redhat.com/show_bug.cgi?id=2070694","https://github.com/torvalds/linux/commit/4e0f718daf97d47cf7dec122da1be970f145c809","https://github.com/torvalds/linux/commit/71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac","https://github.com/torvalds/linux/commit/7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10","https://security.netapp.com/advisory/ntap-20221228-0006/","https://www.openwall.com/lists/oss-security/2022/04/02/5","https://access.redhat.com/security/cve/CVE-2022-1199","https://bugzilla.redhat.com/show_bug.cgi?id=2070694","https://github.com/torvalds/linux/commit/4e0f718daf97d47cf7dec122da1be970f145c809","https://github.com/torvalds/linux/commit/71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac","https://github.com/torvalds/linux/commit/7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10","https://security.netapp.com/advisory/ntap-20221228-0006/","https://www.openwall.com/lists/oss-security/2022/04/02/5"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48657 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: topology: fix possible overflow in amu_fie_setup() cpufreq_get_hw_max_freq() returns max frequency in kHz as *unsigned int*, while freq_inv_set_max_ratio() gets passed this frequency in Hz as 'u64'. Multiplying max frequency by 1000 can potentially result in overflow -- multiplying by 1000ULL instead should avoid that... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | ["https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549","https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e","https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb","https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca","https://git.kernel.org/stable/c/3c3edb82d67b2be9231174ac2af4af60d4af7549","https://git.kernel.org/stable/c/904f881b57360cf85de962d84d8614d94431f60e","https://git.kernel.org/stable/c/bb6d99e27cbe6b30e4e3bbd32927fd3b0bdec6eb","https://git.kernel.org/stable/c/d4955c0ad77dbc684fc716387070ac24801b8bca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48686 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix UAF when detecting digest errors We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted. | ["https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5","https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea","https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3","https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff","https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886","https://git.kernel.org/stable/c/13c80a6c112467bab5e44d090767930555fc17a5","https://git.kernel.org/stable/c/160f3549a907a50e51a8518678ba2dcf2541abea","https://git.kernel.org/stable/c/19816a0214684f70b49b25075ff8c402fdd611d3","https://git.kernel.org/stable/c/5914fa32ef1b7766fea933f9eed94ac5c00aa7ff","https://git.kernel.org/stable/c/c3eb461aa56e6fa94fb80442ba2586bd223a8886"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26817 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow. | ["https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a","https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7","https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29","https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0","https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad","https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751","https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a","https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91","https://git.kernel.org/stable/c/0c33d11153949310d76631d8f4a4736519eacd3a","https://git.kernel.org/stable/c/315eb3c2df7e4cb18e3eacfa18a53a46f2bf0ef7","https://git.kernel.org/stable/c/3b0daecfeac0103aba8b293df07a0cbaf8b43f29","https://git.kernel.org/stable/c/8b0564704255c6b3c6a7188e86939f754e1577c0","https://git.kernel.org/stable/c/cbac7de1d9901521e78cdc34e15451df3611f2ad","https://git.kernel.org/stable/c/e6721ea845fcb93a764a92bd40f1afc0d6c69751","https://git.kernel.org/stable/c/e6768c6737f4c02cba193a3339f0cc2907f0b86a","https://git.kernel.org/stable/c/fcbd99b3c73309107e3be71f20dff9414df64f91","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32248 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_TREE_CONNECT and SMB2_QUERY_INFO commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. | ["https://access.redhat.com/security/cve/CVE-2023-32248","https://bugzilla.redhat.com/show_bug.cgi?id=2219818","https://security.netapp.com/advisory/ntap-20230915-0006/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/","https://access.redhat.com/security/cve/CVE-2023-32248","https://bugzilla.redhat.com/show_bug.cgi?id=2219818","https://security.netapp.com/advisory/ntap-20230915-0006/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20479/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48999 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: Handle attempt to delete multipath route when fib_info contains an nh reference Gwangun Jung reported a slab-out-of-bounds access in fib_nh_match: fib_nh_match+0xf98/0x1130 linux-6.0-rc7/net/ipv4/fib_semantics.c:961 fib_table_delete+0x5f3/0xa40 linux-6.0-rc7/net/ipv4/fib_trie.c:1753 inet_rtm_delroute+0x2b3/0x380 linux-6.0-rc7/net/ipv4/fib_frontend.c:874 Separate nexthop objects are mutually exclusive with the legacy multipath spec. Fix fib_nh_match to return if the config for the to be deleted route contains a multipath spec while the fib_info is using a nexthop object. | ["https://git.kernel.org/stable/c/0b5394229ebae09afc07aabccb5ffd705ffd250e","https://git.kernel.org/stable/c/25174d91e4a32a24204060d283bd5fa6d0ddf133","https://git.kernel.org/stable/c/61b91eb33a69c3be11b259c5ea484505cd79f883","https://git.kernel.org/stable/c/bb20a2ae241be846bc3c11ea4b3a3c69e41d51f2","https://git.kernel.org/stable/c/cc3cd130ecfb8b0ae52e235e487bae3f16a24a32"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32258 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_LOGOFF and SMB2_CLOSE commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. | ["https://access.redhat.com/security/cve/CVE-2023-32258","https://bugzilla.redhat.com/show_bug.cgi?id=2219809","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/","https://access.redhat.com/security/cve/CVE-2023-32258","https://bugzilla.redhat.com/show_bug.cgi?id=2219809","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20796/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58087 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix racy issue from session lookup and expire Increment the session reference count within the lock for lookup to avoid racy issue with session expire. | ["https://git.kernel.org/stable/c/2107ab40629aeabbec369cf34b8cf0f288c3eb1b","https://git.kernel.org/stable/c/37a0e2b362b3150317fb6e2139de67b1e29ae5ff","https://git.kernel.org/stable/c/450a844c045ff0895d41b05a1cbe8febd1acfcfd","https://git.kernel.org/stable/c/a39e31e22a535d47b14656a7d6a893c7f6cf758c","https://git.kernel.org/stable/c/b95629435b84b9ecc0c765995204a4d8a913ed52","https://www.zerodayinitiative.com/advisories/ZDI-25-100/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-1999-0524 | Low | N/A | ICMP information such as (1) netmask and (2) timestamp is allowed from arbitrary hosts. | ["http://descriptions.securescout.com/tc/11010","http://descriptions.securescout.com/tc/11011","http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10705","http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC\u0026externalId=1434","http://www.osvdb.org/95","https://exchange.xforce.ibmcloud.com/vulnerabilities/306","https://exchange.xforce.ibmcloud.com/vulnerabilities/322","https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10053","http://descriptions.securescout.com/tc/11010","http://descriptions.securescout.com/tc/11011","http://kb.juniper.net/InfoCenter/index?page=content\u0026id=JSA10705","http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC\u0026externalId=1434","http://www.osvdb.org/95","https://exchange.xforce.ibmcloud.com/vulnerabilities/306","https://exchange.xforce.ibmcloud.com/vulnerabilities/322","https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10053","https://support.f5.com/csp/article/K15277"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39490 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix missing sk_buff release in seg6_input_core The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak. This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks. The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails. | ["https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9","https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864","https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a","https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8","https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940","https://git.kernel.org/stable/c/5447f9708d9e4c17a647b16a9cb29e9e02820bd9","https://git.kernel.org/stable/c/8f1fc3b86eaea70be6abcae2e9aa7e7b99453864","https://git.kernel.org/stable/c/e8688218e38111ace457509d8f0cad75f79c1a7a","https://git.kernel.org/stable/c/f4df8c7670a73752201cbde215254598efdf6ce8","https://git.kernel.org/stable/c/f5fec1588642e415a3d72e02140160661b303940"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52442 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate session id and tree id in compound request `smb2_get_msg()` in smb2_get_ksmbd_tcon() and smb2_check_user_session() will always return the first request smb2 header in a compound request. if `SMB2_TREE_CONNECT_HE` is the first command in compound request, will return 0, i.e. The tree id check is skipped. This patch use ksmbd_req_buf_next() to get current command in compound. | ["https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693","https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e","https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac","https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f","https://git.kernel.org/stable/c/017d85c94f02090a87f4a473dbe0d6ee0da72693","https://git.kernel.org/stable/c/3df0411e132ee74a87aa13142dfd2b190275332e","https://git.kernel.org/stable/c/4c2b350b2e269e3fd17bbfa42de1b42775b777ac","https://git.kernel.org/stable/c/becb5191d1d5fdfca0198a2e37457bbbf4fe266f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52738 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini Currently amdgpu calls drm_sched_fini() from the fence driver sw fini routine - such function is expected to be called only after the respective init function - drm_sched_init() - was executed successfully. Happens that we faced a driver probe failure in the Steam Deck recently, and the function drm_sched_fini() was called even without its counter-part had been previously called, causing the following oops: amdgpu: probe of 0000:04:00.0 failed with error -110 BUG: kernel NULL pointer dereference, address: 0000000000000090 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022 RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace: <TASK> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu] amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] devm_drm_dev_init_release+0x49/0x70 [...] To prevent that, check if the drm_sched was properly initialized for a given ring before calling its fini counter-part. Notice ideally we'd use sched.ready for that; such field is set as the latest thing on drm_sched_init(). But amdgpu seems to "override" the meaning of such field - in the above oops for example, it was a GFX ring causing the crash, and the sched.ready field was set to true in the ring init routine, regardless of the state of the DRM scheduler. Hence, we ended-up using sched.ops as per Christian's suggestion [0], and also removed the no_scheduler check [1]. [0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/ [1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/ | ["https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b","https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd","https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535","https://git.kernel.org/stable/c/2bcbbef9cace772f5b7128b11401c515982de34b","https://git.kernel.org/stable/c/2e557c8ca2c585bdef591b8503ba83b85f5d0afd","https://git.kernel.org/stable/c/5ad7bbf3dba5c4a684338df1f285080f2588b535"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47942 | High | fixed |
|
An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in set_ntacl_dacl, related to use of SMB2_QUERY_INFO_HE after a malformed SMB2_SET_INFO_HE command. | ["http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://www.zerodayinitiative.com/advisories/ZDI-22-1688/","http://www.openwall.com/lists/oss-security/2022/12/23/10","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://github.com/torvalds/linux/commit/8f0541186e9ad1b62accc9519cc2b7a7240272a7","https://www.zerodayinitiative.com/advisories/ZDI-22-1688/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1193 | Medium | fixed |
|
A use-after-free flaw was found in setup_async_work in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. This issue could allow an attacker to crash the system by accessing freed work. | ["https://access.redhat.com/security/cve/CVE-2023-1193","https://bugzilla.redhat.com/show_bug.cgi?id=2154177","https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/","https://access.redhat.com/security/cve/CVE-2023-1193","https://bugzilla.redhat.com/show_bug.cgi?id=2154177","https://lkml.kernel.org/linux-cifs/20230401084951.6085-2-linkinjeon@kernel.org/T/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-20194 | High | N/A | There is a vulnerability in the linux kernel versions higher than 5.2 (if kernel compiled with config params CONFIG_BPF_SYSCALL=y , CONFIG_BPF=y , CONFIG_CGROUPS=y , CONFIG_CGROUP_BPF=y , CONFIG_HARDENED_USERCOPY not set, and BPF hook to getsockopt is registered). As result of BPF execution, the local user can trigger bug in __cgroup_bpf_run_filter_getsockopt() function that can lead to heap overflow (because of non-hardened usercopy). The impact of attack could be deny of service or possibly privileges escalation. | ["https://bugzilla.redhat.com/show_bug.cgi?id=1912683","https://security.netapp.com/advisory/ntap-20210326-0003/","https://bugzilla.redhat.com/show_bug.cgi?id=1912683","https://security.netapp.com/advisory/ntap-20210326-0003/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1729 | High | fixed |
|
A race condition was found the Linux kernel in perf_event_open() which can be exploited by an unprivileged user to gain root privileges. The bug allows to build several exploit primitives such as kernel address information leak, arbitrary execution, etc. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704","https://security.netapp.com/advisory/ntap-20230214-0006/","https://www.openwall.com/lists/oss-security/2022/05/20/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3ac6487e584a1eb54071dbe1212e05b884136704","https://security.netapp.com/advisory/ntap-20230214-0006/","https://www.openwall.com/lists/oss-security/2022/05/20/2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38556 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Add a timeout to acquire the command queue semaphore Prevent forced completion handling on an entry that has not yet been assigned an index, causing an out of bounds access on idx = -22. Instead of waiting indefinitely for the sem, blocking flow now waits for index to be allocated or a sem acquisition timeout before beginning the timer for FW completion. Kernel log example: mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion | ["https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918","https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7","https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6","https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b","https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319","https://git.kernel.org/stable/c/2d0962d05c93de391ce85f6e764df895f47c8918","https://git.kernel.org/stable/c/485d65e1357123a697c591a5aeb773994b247ad7","https://git.kernel.org/stable/c/4baae687a20ef2b82fde12de3c04461e6f2521d6","https://git.kernel.org/stable/c/94024332a129c6e4275569d85c0c1bfb2ae2d71b","https://git.kernel.org/stable/c/f9caccdd42e999b74303c9b0643300073ed5d319"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2163 | High | fixed |
|
Incorrect verifier pruning in BPF in Linux Kernel >=5.4 leads to unsafe code paths being incorrectly marked as safe, resulting in arbitrary read/write in kernel memory, lateral privilege escalation, and container escape. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed","https://bughunters.google.com/blog/6303226026131456/a-deep-dive-into-cve-2023-2163-how-we-found-and-fixed-an-ebpf-linux-kernel-vulnerability","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71b547f561247897a0a14f3082730156c0533fed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-25375 | Medium | fixed |
|
An issue was discovered in drivers/usb/gadget/function/rndis.c in the Linux kernel before 5.16.10. The RNDIS USB gadget lacks validation of the size of the RNDIS_MSG_SET command. Attackers can obtain sensitive information from kernel memory. | ["http://www.openwall.com/lists/oss-security/2022/02/21/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/rndis-co","https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","http://www.openwall.com/lists/oss-security/2022/02/21/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/rndis-co","https://github.com/torvalds/linux/commit/38ea1eac7d88072bbffb630e2b3db83ca649b826","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32257 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP and SMB2_LOGOFF commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. | ["https://access.redhat.com/security/cve/CVE-2023-32257","https://bugzilla.redhat.com/show_bug.cgi?id=2219806","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/","https://access.redhat.com/security/cve/CVE-2023-32257","https://bugzilla.redhat.com/show_bug.cgi?id=2219806","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20596/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38427 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemble_neg_contexts. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b","https://security.netapp.com/advisory/ntap-20230824-0011/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=f1a411873c85b642f13b01f21b534c2bab81fc1b","https://security.netapp.com/advisory/ntap-20230824-0011/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44986 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in ip6_finish_output2() If skb_expand_head() returns NULL, skb has been freed and associated dst/idev could also have been freed. We need to hold rcu_read_lock() to make sure the dst and associated idev are alive. | ["https://git.kernel.org/stable/c/3574d28caf9a09756ae87ad1ea096c6f47b6101e","https://git.kernel.org/stable/c/56efc253196751ece1fc535a5b582be127b0578a","https://git.kernel.org/stable/c/6ab6bf731354a6fdbaa617d1ec194960db61cf3b","https://git.kernel.org/stable/c/da273b377ae0d9bd255281ed3c2adb228321687b","https://git.kernel.org/stable/c/e891b36de161fcd96f12ff83667473e5067b9037"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32250 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_SESSION_SETUP commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. | ["https://access.redhat.com/security/cve/CVE-2023-32250","https://bugzilla.redhat.com/show_bug.cgi?id=2208849","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-698/","https://access.redhat.com/security/cve/CVE-2023-32250","https://bugzilla.redhat.com/show_bug.cgi?id=2208849","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-698/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26739 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(), yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the retval override to the error path which actually need it. | ["https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210","https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d","https://git.kernel.org/stable/c/9d3ef89b6a5e9f2e940de2cef3d543be0be8dec5","https://git.kernel.org/stable/c/e873e8f7d03a2ee5b77fb1a305c782fed98e2754","https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7","https://git.kernel.org/stable/c/166c2c8a6a4dc2e4ceba9e10cfe81c3e469e3210","https://git.kernel.org/stable/c/28cdbbd38a4413b8eff53399b3f872fd4e80db9d","https://git.kernel.org/stable/c/f4e294bbdca8ac8757db436fc82214f3882fc7e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46774 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/rtas: Prevent Spectre v1 gadget construction in sys_rtas() Smatch warns: arch/powerpc/kernel/rtas.c:1932 __do_sys_rtas() warn: potential spectre issue 'args.args' [r] (local cap) The 'nargs' and 'nret' locals come directly from a user-supplied buffer and are used as indexes into a small stack-based array and as inputs to copy_to_user() after they are subject to bounds checks. Use array_index_nospec() after the bounds checks to clamp these values for speculative execution. | ["https://git.kernel.org/stable/c/0974d03eb479384466d828d65637814bee6b26d7","https://git.kernel.org/stable/c/1f1feff02e9da0dd0cdb195c428c42b5f9b6c771","https://git.kernel.org/stable/c/68d8156480940b79227d58865ec5d2947b9384a8","https://git.kernel.org/stable/c/a262c2dc833f2fe1bd5c53a4d899e7077d3b1da9","https://git.kernel.org/stable/c/b137af795399d8b657bad1646c18561530f35ed1","https://git.kernel.org/stable/c/d2834ff1d9641a8695a09ea79cd901c7b6d4d05f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52667 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: fix a potential double-free in fs_any_create_groups When kcalloc() for ft->g succeeds but kvzalloc() for in fails, fs_any_create_groups() will free ft->g. However, its caller fs_any_create_table() will free ft->g again through calling mlx5e_destroy_flow_table(), which will lead to a double-free. Fix this by setting ft->g to NULL in fs_any_create_groups(). | ["https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8","https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779","https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1","https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e","https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe","https://git.kernel.org/stable/c/2897c981ee63e1be5e530b1042484626a10b26d8","https://git.kernel.org/stable/c/65a4ade8a6d205979292e88beeb6a626ddbd4779","https://git.kernel.org/stable/c/72a729868592752b5a294d27453da264106983b1","https://git.kernel.org/stable/c/aef855df7e1bbd5aa4484851561211500b22707e","https://git.kernel.org/stable/c/b2fa86b2aceb4bc9ada51cea90f61546d7512cbe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32247 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. | ["https://access.redhat.com/security/cve/CVE-2023-32247","https://bugzilla.redhat.com/show_bug.cgi?id=2219803","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/","https://access.redhat.com/security/cve/CVE-2023-32247","https://bugzilla.redhat.com/show_bug.cgi?id=2219803","https://security.netapp.com/advisory/ntap-20230915-0011/","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20478/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-29582 | High | fixed |
|
In the Linux kernel before 5.17.3, fs/io_uring.c has a use-after-free due to a race condition in io_uring timeouts. This can be triggered by a local user who has no access to any user namespace; however, the race condition perhaps can only be exploited infrequently. | ["http://www.openwall.com/lists/oss-security/2022/04/22/4","http://www.openwall.com/lists/oss-security/2022/08/08/3","http://www.openwall.com/lists/oss-security/2024/04/24/3","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646","https://github.com/Ruia-ruia/CVE-2022-29582-Exploit","https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646","https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/","https://www.debian.org/security/2022/dsa-5127","https://www.openwall.com/lists/oss-security/2022/04/22/3","http://www.openwall.com/lists/oss-security/2022/04/22/4","http://www.openwall.com/lists/oss-security/2022/08/08/3","http://www.openwall.com/lists/oss-security/2024/04/24/3","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e677edbcabee849bfdd43f1602bccbecf736a646","https://github.com/Ruia-ruia/CVE-2022-29582-Exploit","https://github.com/torvalds/linux/commit/e677edbcabee849bfdd43f1602bccbecf736a646","https://ruia-ruia.github.io/2022/08/05/CVE-2022-29582-io-uring/","https://www.debian.org/security/2022/dsa-5127","https://www.openwall.com/lists/oss-security/2022/04/22/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-10902 | High | N/A | It was found that the raw midi kernel driver does not protect against concurrent access which leads to a double realloc (double free) in snd_rawmidi_input_params() and snd_rawmidi_output_status() which are part of snd_rawmidi_ioctl() handler in rawmidi.c file. A malicious local attacker could possibly use this for privilege escalation. | ["http://www.securityfocus.com/bid/105119","http://www.securitytracker.com/id/1041529","https://access.redhat.com/errata/RHSA-2018:3083","https://access.redhat.com/errata/RHSA-2018:3096","https://access.redhat.com/errata/RHSA-2019:0415","https://access.redhat.com/errata/RHSA-2019:0641","https://access.redhat.com/errata/RHSA-2019:3217","https://access.redhat.com/errata/RHSA-2019:3967","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10902","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39675f7a7c7e7702f7d5341f1e0d01db746543a0","https://lists.debian.org/debian-lts-announce/2018/10/msg00003.html","https://usn.ubuntu.com/3776-1/","https://usn.ubuntu.com/3776-2/","https://usn.ubuntu.com/3847-1/","https://usn.ubuntu.com/3847-2/","https://usn.ubuntu.com/3847-3/","https://usn.ubuntu.com/3849-1/","https://usn.ubuntu.com/3849-2/","https://www.debian.org/security/2018/dsa-4308","http://www.securityfocus.com/bid/105119","http://www.securitytracker.com/id/1041529","https://access.redhat.com/errata/RHSA-2018:3083","https://access.redhat.com/errata/RHSA-2018:3096","https://access.redhat.com/errata/RHSA-2019:0415","https://access.redhat.com/errata/RHSA-2019:0641","https://access.redhat.com/errata/RHSA-2019:3217","https://access.redhat.com/errata/RHSA-2019:3967","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10902","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=39675f7a7c7e7702f7d5341f1e0d01db746543a0","https://lists.debian.org/debian-lts-announce/2018/10/msg00003.html","https://usn.ubuntu.com/3776-1/","https://usn.ubuntu.com/3776-2/","https://usn.ubuntu.com/3847-1/","https://usn.ubuntu.com/3847-2/","https://usn.ubuntu.com/3847-3/","https://usn.ubuntu.com/3849-1/","https://usn.ubuntu.com/3849-2/","https://www.debian.org/security/2018/dsa-4308"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3390 | High | fixed |
|
A use-after-free vulnerability was found in the Linux kernel's netfilter subsystem in net/netfilter/nf_tables_api.c. Mishandled error handling with NFT_MSG_NEWRULE makes it possible to use a dangling pointer in the same transaction causing a use-after-free vulnerability. This flaw allows a local attacker with user access to cause a privilege escalation issue. We recommend upgrading past commit 1240eb93f0616b21c675416516ff3d74798fdc97. | ["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97","https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0004/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5461","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1240eb93f0616b21c675416516ff3d74798fdc97","https://kernel.dance/1240eb93f0616b21c675416516ff3d74798fdc97","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0004/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5461"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38432 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.10. fs/smb/server/smb2misc.c in ksmbd does not validate the relationship between the command payload size and the RFC1002 length specification, leading to an out-of-bounds read. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d","https://security.netapp.com/advisory/ntap-20230831-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=2b9b8f3b68edb3d67d79962f02e26dbb5ae3808d","https://security.netapp.com/advisory/ntap-20230831-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1679 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s Atheros wireless adapter driver in the way a user forces the ath9k_htc_wait_for_target function to fail with some input messages. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/","https://security.netapp.com/advisory/ntap-20220629-0007/","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/lkml/87ilqc7jv9.fsf%40kernel.org/t/","https://security.netapp.com/advisory/ntap-20220629-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36894 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following: DWC3 Gadget FFS Application dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue() There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer. commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock. Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it. This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") | ["https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19","https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a","https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb","https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867","https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14","https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4","https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd","https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311","https://git.kernel.org/stable/c/24729b307eefcd7c476065cd7351c1a018082c19","https://git.kernel.org/stable/c/3613e5023f09b3308545e9d1acda86017ebd418a","https://git.kernel.org/stable/c/73c05ad46bb4fbbdb346004651576d1c8dbcffbb","https://git.kernel.org/stable/c/9e72ef59cbe61cd1243857a6418ca92104275867","https://git.kernel.org/stable/c/a0fdccb1c9e027e3195f947f61aa87d6d0d2ea14","https://git.kernel.org/stable/c/d7461830823242702f5d84084bcccb25159003f4","https://git.kernel.org/stable/c/e500b1c4e29ad0bd1c1332a1eaea2913627a92dd","https://git.kernel.org/stable/c/f71a53148ce34898fef099b75386a3a9f4449311"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48855 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: fix kernel-infoleak for SCTP sockets syzbot reported a kernel infoleak [1] of 4 bytes. After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill() Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0 CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | ["https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83","https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5","https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7","https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8","https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c","https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545","https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8","https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08","https://git.kernel.org/stable/c/1502f15b9f29c41883a6139f2923523873282a83","https://git.kernel.org/stable/c/2d8fa3fdf4542a2174a72d92018f488d65d848c5","https://git.kernel.org/stable/c/3fc0fd724d199e061432b66a8d85b7d48fe485f7","https://git.kernel.org/stable/c/41a2864cf719c17294f417726edd411643462ab8","https://git.kernel.org/stable/c/633593a808980f82d251d0ca89730d8bb8b0220c","https://git.kernel.org/stable/c/b7e4d9ba2ddb78801488b4c623875b81fb46b545","https://git.kernel.org/stable/c/bbf59d7ae558940cfa2b36a287fd1e88d83f89f8","https://git.kernel.org/stable/c/d828b0fe6631f3ae8709ac9a10c77c5836c76a08"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48672 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: of: fdt: fix off-by-one error in unflatten_dt_nodes() Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | ["https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e","https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0","https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181","https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7","https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853","https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf","https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c","https://git.kernel.org/stable/c/2133f451311671c7c42b5640d2b999326b39aa0e","https://git.kernel.org/stable/c/2566706ac6393386a4e7c4ce23fe17f4c98d9aa0","https://git.kernel.org/stable/c/2f945a792f67815abca26fa8a5e863ccf3fa1181","https://git.kernel.org/stable/c/ba6b9f7cc1108bad6e2c53b1d6e0156379188db7","https://git.kernel.org/stable/c/cbdda20ce363356698835185801a58a28f644853","https://git.kernel.org/stable/c/e0e88c25f88b9805572263c9ed20f1d88742feaf","https://git.kernel.org/stable/c/ee4369260e77821602102dcc7d792de39a56365c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3586 | Medium | fixed |
|
A flaw was found in the Linux kernel’s networking code. A use-after-free was found in the way the sch_sfb enqueue function used the socket buffer (SKB) cb field after the same SKB had been enqueued (and freed) into a child qdisc. This flaw allows a local, unprivileged user to crash the system, causing a denial of service. | ["https://github.com/torvalds/linux/commit/9efd23297cca","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.zerodayinitiative.com/advisories/upcoming/","https://github.com/torvalds/linux/commit/9efd23297cca","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.zerodayinitiative.com/advisories/upcoming/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38426 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. ksmbd has an out-of-bounds read in smb2_find_context_vals when create_context's name_len is larger than the tag length. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85","https://security.netapp.com/advisory/ntap-20230915-0010/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=02f76c401d17e409ed45bf7887148fcc22c93c85","https://security.netapp.com/advisory/ntap-20230915-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38428 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/smb2pdu.c in ksmbd does not properly check the UserName value because it does not consider the address of security buffer, leading to an out-of-bounds read. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f","https://security.netapp.com/advisory/ntap-20230831-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=f0a96d1aafd8964e1f9955c830a3e5cb3c60a90f","https://security.netapp.com/advisory/ntap-20230831-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-44879 | Medium | fixed |
|
In gc_data_segment in fs/f2fs/gc.c in the Linux kernel before 5.16.3, special files are not considered, leading to a move_data_page NULL pointer dereference. | ["https://bugzilla.kernel.org/show_bug.cgi?id=215231","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9056d6489f5a41cfbb67f719d2c0ce61ead72d9f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-f2fs-devel/20211206144421.3735-3-chao%40kernel.org/T/","https://bugzilla.kernel.org/show_bug.cgi?id=215231","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9056d6489f5a41cfbb67f719d2c0ce61ead72d9f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/linux-f2fs-devel/20211206144421.3735-3-chao%40kernel.org/T/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-10840 | Medium | N/A | Linux kernel is vulnerable to a heap-based buffer overflow in the fs/ext4/xattr.c:ext4_xattr_set_entry() function. An attacker could exploit this by operating on a mounted crafted ext4 image. | ["http://www.securityfocus.com/bid/104858","https://access.redhat.com/errata/RHSA-2019:0162","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10840","https://usn.ubuntu.com/3752-1/","https://usn.ubuntu.com/3752-2/","https://usn.ubuntu.com/3752-3/","http://www.securityfocus.com/bid/104858","https://access.redhat.com/errata/RHSA-2019:0162","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10840","https://usn.ubuntu.com/3752-1/","https://usn.ubuntu.com/3752-2/","https://usn.ubuntu.com/3752-3/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32254 | High | fixed |
|
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel. | ["https://access.redhat.com/security/cve/CVE-2023-32254","https://bugzilla.redhat.com/show_bug.cgi?id=2191658","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-702/","https://access.redhat.com/security/cve/CVE-2023-32254","https://bugzilla.redhat.com/show_bug.cgi?id=2191658","https://security.netapp.com/advisory/ntap-20230824-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-702/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26996 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error When ncm function is working and then stop usb0 interface for link down, eth_stop() is called. At this piont, accidentally if usb transport error should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled. After that, ncm_disable() is called to disable for ncm unbind but gether_disconnect() is never called since 'in_ep' is not enabled. As the result, ncm object is released in ncm unbind but 'dev->port_usb' associated to 'ncm->port' is not NULL. And when ncm bind again to recover netdev, ncm object is reallocated but usb0 interface is already associated to previous released ncm object. Therefore, once usb0 interface is up and eth_start_xmit() is called, released ncm object is dereferrenced and it might cause use-after-free memory. [function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm [function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014f This patch addresses the issue by checking if 'ncm->netdev' is not NULL at ncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'. It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnect rather than check 'ncm->port.in_ep->enabled' since it might not be enabled but the gether connection might be established. | ["https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93","https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e","https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7","https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca","https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3","https://git.kernel.org/stable/c/0588bbbd718a8130b98c54518f1e0b569ce60a93","https://git.kernel.org/stable/c/6334b8e4553cc69f51e383c9de545082213d785e","https://git.kernel.org/stable/c/7250326cbb1f4f90391ac511a126b936cefb5bb7","https://git.kernel.org/stable/c/7f67c2020cb08499c400abf0fc32c65e4d9a09ca","https://git.kernel.org/stable/c/f356fd0cbd9c9cbd0854657a80d1608d0d732db3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0458 | Medium | fixed |
|
A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the 'rlim' variable and can be used to leak the contents. We recommend upgrading past version 6.1.8 or commit 739790605705ddcf18f21782b9c99ad7d53a8c11 | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/kernel/sys.c?id=v6.1.8\u0026id2=v6.1.7","https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/kernel/sys.c?id=v6.1.8\u0026id2=v6.1.7","https://github.com/torvalds/linux/commit/739790605705ddcf18f21782b9c99ad7d53a8c11","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49377 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-mq: don't touch ->tagset in blk_mq_get_sq_hctx blk_mq_run_hw_queues() could be run when there isn't queued request and after queue is cleaned up, at that time tagset is freed, because tagset lifetime is covered by driver, and often freed after blk_cleanup_queue() returns. So don't touch ->tagset for figuring out current default hctx by the mapping built in request queue, so use-after-free on tagset can be avoided. Meantime this way should be fast than retrieving mapping from tagset. | ["https://git.kernel.org/stable/c/460aa288c5cd0544dcf933a2f0ad0e8c6d2d35ff","https://git.kernel.org/stable/c/5d05426e2d5fd7df8afc866b78c36b37b00188b7","https://git.kernel.org/stable/c/70fdd922c7bf8949f8df109cf2635dff64c90392","https://git.kernel.org/stable/c/b140bac470b4f707cda59c7266214246238661df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49426 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3-sva: Fix mm use-after-free We currently call arm64_mm_context_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID. | ["https://git.kernel.org/stable/c/9aa215450888cf29af0c479e14a712dc6b0c506c","https://git.kernel.org/stable/c/cbd23144f7662b00bcde32a938c4a4057e476d68","https://git.kernel.org/stable/c/e3cbbdbff8a4db5d053c53fd71be62ccccdb52b0","https://git.kernel.org/stable/c/fc90f13ea0dcd960e5002d204fa55cec4e0db2fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49541 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential double free during failed mount RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=2088799 | ["https://git.kernel.org/stable/c/8378a51e3f8140f60901fb27208cc7a6e47047b5","https://git.kernel.org/stable/c/9a167fc440e5693c1cdd7f07071e05658bd9d89d","https://git.kernel.org/stable/c/ce0008a0e410cdd95f0d8cd81b2902ec10a660c4","https://git.kernel.org/stable/c/ee71f8f1cd3c8c4a251fd3e8abc89215ae3457cb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49548 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix potential array overflow in bpf_trampoline_get_progs() The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline can exceed BPF_MAX_TRAMP_PROGS. When this happens, the assignment '*progs++ = aux->prog' in bpf_trampoline_get_progs() will cause progs array overflow as the progs field in the bpf_tramp_progs struct can only hold at most BPF_MAX_TRAMP_PROGS bpf programs. | ["https://git.kernel.org/stable/c/32c4559c61652f24c9fdd5440342196fe37453bc","https://git.kernel.org/stable/c/4f8897bcc20b9ae44758e0572538d741ab66f0dc","https://git.kernel.org/stable/c/7f845de2863334bed4f362e95853f5e7bc323737","https://git.kernel.org/stable/c/a2aa95b71c9bbec793b5c5fa50f0a80d882b3e8d","https://git.kernel.org/stable/c/e36452d5da6325df7c10cffc60a9e68d21e2606d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49695 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: igb: fix a use-after-free issue in igb_clean_tx_ring Fix the following use-after-free bug in igb_clean_tx_ring routine when the NIC is running in XDP mode. The issue can be triggered redirecting traffic into the igb NIC and then closing the device while the traffic is flowing. [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9 [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0 [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282 [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000 [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0 [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058 [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090 [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000 [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000 [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0 [ 73.426565] Call Trace: [ 73.429087] <TASK> [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb] [ 73.436002] igb_down+0x1d7/0x220 [igb] [ 73.439974] __igb_close+0x3c/0x120 [igb] [ 73.444118] igb_xdp+0x10c/0x150 [igb] [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb] [ 73.453362] dev_xdp_install+0xda/0x110 [ 73.457371] dev_xdp_attach+0x1da/0x550 [ 73.461369] do_setlink+0xfd0/0x10f0 [ 73.465166] ? __nla_validate_parse+0x89/0xc70 [ 73.469714] rtnl_setlink+0x11a/0x1e0 [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0 [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130 [ 73.482258] netlink_rcv_skb+0x8d/0x110 [ 73.486229] netlink_unicast+0x230/0x340 [ 73.490317] netlink_sendmsg+0x215/0x470 [ 73.494395] __sys_sendto+0x179/0x190 [ 73.498268] ? move_addr_to_user+0x37/0x70 [ 73.502547] ? __sys_getsockname+0x84/0xe0 [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0 [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0 [ 73.515636] __x64_sys_sendto+0x20/0x30 [ 73.519603] do_syscall_64+0x3b/0x80 [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 73.528712] RIP: 0033:0x7ff38d41f20c [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003 [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0 [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30 [ 73.596545] </TASK> [ 73.598842] ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/2af944210dc23d43d8208dafac4df7be7e3c168b","https://git.kernel.org/stable/c/3f6a57ee8544ec3982f8a3cbcbf4aea7d47eb9ec","https://git.kernel.org/stable/c/68a0ed06dcd5d3ea732d011c0b83d66e4791f521","https://git.kernel.org/stable/c/c12a2c9b1b460ed72e6b3c33aac1ef51b0329b66"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49696 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: fix use-after-free Read in tipc_named_reinit syzbot found the following issue on: ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764 CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted 5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK> [...] ================================================================== In the commit d966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"), the cancel_work_sync() function just to make sure ONLY the work tipc_net_finalize_work() is executing/pending on any CPU completed before tipc namespace is destroyed through tipc_exit_net(). But this function is not guaranteed the work is the last queued. So, the destroyed instance may be accessed in the work which will try to enqueue later. In order to completely fix, we re-order the calling of cancel_work_sync() to make sure the work tipc_net_finalize_work() was last queued and it must be completed by calling cancel_work_sync(). | ["https://git.kernel.org/stable/c/361c5521c1e49843b710f455cae3c0a50b714323","https://git.kernel.org/stable/c/8b246ddd394d7d9640816611693b0096b998e27a","https://git.kernel.org/stable/c/911600bf5a5e84bfda4d33ee32acc75ecf6159f0","https://git.kernel.org/stable/c/cd7789e659e84f137631dc1f5ec8d794f2700e6c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49720 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: Fix handling of offline queues in blk_mq_alloc_request_hctx() This patch prevents that test nvme/004 triggers the following: UBSAN: array-index-out-of-bounds in block/blk-mq.h:135:9 index 512 is out of range for type 'long unsigned int [512]' Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x3b __ubsan_handle_out_of_bounds.cold+0x44/0x49 blk_mq_alloc_request_hctx+0x304/0x310 __nvme_submit_sync_cmd+0x70/0x200 [nvme_core] nvmf_connect_io_queue+0x23e/0x2a0 [nvme_fabrics] nvme_loop_connect_io_queues+0x8d/0xb0 [nvme_loop] nvme_loop_create_ctrl+0x58e/0x7d0 [nvme_loop] nvmf_create_ctrl+0x1d7/0x4d0 [nvme_fabrics] nvmf_dev_write+0xae/0x111 [nvme_fabrics] vfs_write+0x144/0x560 ksys_write+0xb7/0x140 __x64_sys_write+0x42/0x50 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/14dc7a18abbe4176f5626c13c333670da8e06aa1","https://git.kernel.org/stable/c/7fa28a7c3d74933a4fc22d341b60927952f31c19","https://git.kernel.org/stable/c/b202a0bd2580ee5b0453772c46d464152fafff73","https://git.kernel.org/stable/c/b5e65ef044d627effdc2599040b6d204e003f955"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3643 | Medium | fixed |
|
Guests can trigger NIC interface reset/abort/crash via netback It is possible for a guest to trigger a NIC interface reset/abort/crash in a Linux based network backend by sending certain kinds of packets. It appears to be an (unwritten?) assumption in the rest of the Linux network stack that packet protocol headers are all contained within the linear section of the SKB and some NICs behave badly if this is not the case. This has been reported to occur with Cisco (enic) and Broadcom NetXtrem II BCM5780 (bnx2x) though it may be an issue with other NICs/drivers as well. In case the frontend is sending requests with split headers, netback will forward those violating above mentioned assumption to the networking core, resulting in said misbehavior. | ["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","http://www.openwall.com/lists/oss-security/2022/12/07/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-423.txt","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","http://www.openwall.com/lists/oss-security/2022/12/07/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-423.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48658 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context. Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations __free_slab() invocations out of IRQ context") moved all flush_cpu_slab() invocations to the global workqueue to avoid a problem related with deactivate_slab()/__free_slab() being called from an IRQ context on PREEMPT_RT kernels. When the flush_all_cpu_locked() function is called from a task context it may happen that a workqueue with WQ_MEM_RECLAIM bit set ends up flushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core] Fix this bug by creating a workqueue for the flush operation with the WQ_MEM_RECLAIM bit set. | ["https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b","https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a","https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729","https://git.kernel.org/stable/c/61703b248be993eb4997b00ae5d3318e6d8f3c5b","https://git.kernel.org/stable/c/df6cb39335cf5a1b918e8dbd8ba7cd9f1d00e45a","https://git.kernel.org/stable/c/e45cc288724f0cfd497bb5920bcfa60caa335729"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48662 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Really move i915_gem_context.link under ref protection i915_perf assumes that it can use the i915_gem_context reference to protect its i915->gem.contexts.list iteration. However, this requires that we do not remove the context from the list until after we drop the final reference and release the struct. If, as currently, we remove the context from the list during context_close(), the link.next pointer may be poisoned while we are holding the context reference and cause a GPF: [ 4070.573157] i915 0000:00:02.0: [drm:i915_perf_open_ioctl [i915]] filtering on ctx_id=0x1fffff ctx_id_mask=0x1fffff [ 4070.574881] general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP [ 4070.574897] CPU: 1 PID: 284392 Comm: amd_performance Tainted: G E 5.17.9 #180 [ 4070.574903] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 4070.574907] RIP: 0010:oa_configure_all_contexts.isra.0+0x222/0x350 [i915] [ 4070.574982] Code: 08 e8 32 6e 10 e1 4d 8b 6d 50 b8 ff ff ff ff 49 83 ed 50 f0 41 0f c1 04 24 83 f8 01 0f 84 e3 00 00 00 85 c0 0f 8e fa 00 00 00 <49> 8b 45 50 48 8d 70 b0 49 8d 45 50 48 39 44 24 10 0f 85 34 fe ff [ 4070.574990] RSP: 0018:ffffc90002077b78 EFLAGS: 00010202 [ 4070.574995] RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000000 [ 4070.575000] RDX: 0000000000000001 RSI: ffffc90002077b20 RDI: ffff88810ddc7c68 [ 4070.575004] RBP: 0000000000000001 R08: ffff888103242648 R09: fffffffffffffffc [ 4070.575008] R10: ffffffff82c50bc0 R11: 0000000000025c80 R12: ffff888101bf1860 [ 4070.575012] R13: dead0000000000b0 R14: ffffc90002077c04 R15: ffff88810be5cabc [ 4070.575016] FS: 00007f1ed50c0780(0000) GS:ffff88885ec80000(0000) knlGS:0000000000000000 [ 4070.575021] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4070.575025] CR2: 00007f1ed5590280 CR3: 000000010ef6f005 CR4: 00000000003706e0 [ 4070.575029] Call Trace: [ 4070.575033] <TASK> [ 4070.575037] lrc_configure_all_contexts+0x13e/0x150 [i915] [ 4070.575103] gen8_enable_metric_set+0x4d/0x90 [i915] [ 4070.575164] i915_perf_open_ioctl+0xbc0/0x1500 [i915] [ 4070.575224] ? asm_common_interrupt+0x1e/0x40 [ 4070.575232] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575290] drm_ioctl_kernel+0x85/0x110 [ 4070.575296] ? update_load_avg+0x5f/0x5e0 [ 4070.575302] drm_ioctl+0x1d3/0x370 [ 4070.575307] ? i915_oa_init_reg_state+0x110/0x110 [i915] [ 4070.575382] ? gen8_gt_irq_handler+0x46/0x130 [i915] [ 4070.575445] __x64_sys_ioctl+0x3c4/0x8d0 [ 4070.575451] ? __do_softirq+0xaa/0x1d2 [ 4070.575456] do_syscall_64+0x35/0x80 [ 4070.575461] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 4070.575467] RIP: 0033:0x7f1ed5c10397 [ 4070.575471] Code: 3c 1c e8 1c ff ff ff 85 c0 79 87 49 c7 c4 ff ff ff ff 5b 5d 4c 89 e0 41 5c c3 66 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a9 da 0d 00 f7 d8 64 89 01 48 [ 4070.575478] RSP: 002b:00007ffd65c8d7a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 4070.575484] RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f1ed5c10397 [ 4070.575488] RDX: 00007ffd65c8d7c0 RSI: 0000000040106476 RDI: 0000000000000006 [ 4070.575492] RBP: 00005620972f9c60 R08: 000000000000000a R09: 0000000000000005 [ 4070.575496] R10: 000000000000000d R11: 0000000000000246 R12: 000000000000000a [ 4070.575500] R13: 000000000000000d R14: 0000000000000000 R15: 00007ffd65c8d7c0 [ 4070.575505] </TASK> [ 4070.575507] Modules linked in: nls_ascii(E) nls_cp437(E) vfat(E) fat(E) i915(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) crct10dif_pclmul(E) crc32_pclmul(E) crc32c_intel(E) aesni_intel(E) crypto_simd(E) intel_gtt(E) cryptd(E) ttm(E) rapl(E) intel_cstate(E) drm_kms_helper(E) cfbfillrect(E) syscopyarea(E) cfbimgblt(E) intel_uncore(E) sysfillrect(E) mei_me(E) sysimgblt(E) i2c_i801(E) fb_sys_fops(E) mei(E) intel_pch_thermal(E) i2c_smbus ---truncated--- | ["https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1","https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02","https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d","https://git.kernel.org/stable/c/713fa3e4591f65f804bdc88e8648e219fabc9ee1","https://git.kernel.org/stable/c/d119888b09bd567e07c6b93a07f175df88857e02","https://git.kernel.org/stable/c/f799e0568d6c153368b177e0bbbde7dcc4ce7f1d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52818 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7 For pptable structs that use flexible array sizes, use flexible arrays. | ["https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94","https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3","https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4","https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97","https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47","https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f","https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928","https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498","https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b","https://git.kernel.org/stable/c/6dffdddfca818c02a42b6caa1d9845995f0a1f94","https://git.kernel.org/stable/c/760efbca74a405dc439a013a5efaa9fadc95a8c3","https://git.kernel.org/stable/c/8af28ae3acb736ada4ce3457662fa446cc913bb4","https://git.kernel.org/stable/c/92a775e7c9707aed28782bafe636bf87675f5a97","https://git.kernel.org/stable/c/acdb6830de02cf2873aeaccdf2d9bca4aee50e47","https://git.kernel.org/stable/c/c847379a5d00078ad6fcb1c24230e72c5609342f","https://git.kernel.org/stable/c/cfd8cd907fd94538561479a43aea455f5cf16928","https://git.kernel.org/stable/c/e52e324a21341c97350d5f11de14721c1c609498","https://git.kernel.org/stable/c/fc9ac0e8e0bcb3740c6eaad3a1a50c20016d422b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49560 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: exfat: check if cluster num is valid Syzbot reported slab-out-of-bounds read in exfat_clear_bitmap. This was triggered by reproducer calling truncute with size 0, which causes the following trace: BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65 Move the is_valid_cluster() helper from fatent.c to a common header to make it reusable in other *.c files. And add is_valid_cluster() to validate if cluster number is within valid range in exfat_clear_bitmap() and exfat_set_bitmap(). | ["https://git.kernel.org/stable/c/2193286402df2d9c53294f7a858d5e6fd7346e08","https://git.kernel.org/stable/c/64ba4b15e5c045f8b746c6da5fc9be9a6b00b61d","https://git.kernel.org/stable/c/7c58b14b6f9cde9f69e7fa053ab73f6e013a7131","https://git.kernel.org/stable/c/82f723b8a5adf497f9e34c702a30ca7298615654","https://git.kernel.org/stable/c/c504167adc3248095a905fa0700a9693897cb5ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52733 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/decompressor: specify __decompress() buf len to avoid overflow Historically calls to __decompress() didn't specify "out_len" parameter on many architectures including s390, expecting that no writes beyond uncompressed kernel image are performed. This has changed since commit 2aa14b1ab2c4 ("zstd: import usptream v1.5.2") which includes zstd library commit 6a7ede3dfccb ("Reduce size of dctx by reutilizing dst buffer (#2751)"). Now zstd decompression code might store literal buffer in the unwritten portion of the destination buffer. Since "out_len" is not set, it is considered to be unlimited and hence free to use for optimization needs. On s390 this might corrupt initrd or ipl report which are often placed right after the decompressor buffer. Luckily the size of uncompressed kernel image is already known to the decompressor, so to avoid the problem simply specify it in the "out_len" parameter. | ["https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb","https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2","https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b","https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9","https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2","https://git.kernel.org/stable/c/16409f7d9ca5bb8220e1049ea9aae0d3c94d2dfb","https://git.kernel.org/stable/c/55dbd6f4ea954751340f4f73d5dcd7c8f12208b2","https://git.kernel.org/stable/c/7ab41c2c08a32132ba8c14624910e2fe8ce4ba4b","https://git.kernel.org/stable/c/9ed522143f959630f8b7782ddc212900d8f609a9","https://git.kernel.org/stable/c/f1eb22d0ff064ad458b3b1a1eaa84ac3996206c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-46838 | High | fixed |
|
Transmit requests in Xen's virtual network protocol can consist of multiple parts. While not really useful, except for the initial part any of them may be of zero length, i.e. carry no data at all. Besides a certain initial portion of the to be transferred data, these parts are directly translated into what Linux calls SKB fragments. Such converted request parts can, when for a particular SKB they are all of length zero, lead to a de-reference of NULL in core networking code. | ["https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/","https://xenbits.xenproject.org/xsa/advisory-448.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RGEKT4DKSDXDS34EL7M4UVJMMPH7Z3ZZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZFYW6R64GPLUOXSQBJI3JBUX3HGLAYPP/","https://xenbits.xenproject.org/xsa/advisory-448.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48695 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use-after-free warning Fix the following use-after-free warning which is observed during controller reset: refcount_t: underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0 | ["https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b","https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5","https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7","https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16","https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34","https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82","https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6","https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057","https://git.kernel.org/stable/c/41acb064c4e013808bc7d5fc1b506fa449425b0b","https://git.kernel.org/stable/c/5682c94644fde72f72bded6580c38189ffc856b5","https://git.kernel.org/stable/c/6229fa494a5949be209bc73afbc5d0a749c2e3c7","https://git.kernel.org/stable/c/82efb917eeb27454dc4c6fe26432fc8f6c75bc16","https://git.kernel.org/stable/c/991df3dd5144f2e6b1c38b8d20ed3d4d21e20b34","https://git.kernel.org/stable/c/b8fc9e91b931215110ba824d1a2983c5f60b6f82","https://git.kernel.org/stable/c/d4959d09b76eb7a4146f5133962b88d3bddb63d6","https://git.kernel.org/stable/c/ea10a652ad2ae2cf3eced6f632a5c98f26727057"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52707 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/psi: Fix use-after-free in ep_remove_wait_queue() If a non-root cgroup gets removed when there is a thread that registered trigger and is polling on a pressure file within the cgroup, the polling waitqueue gets freed in the following path: do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy However, the polling thread still has a reference to the pressure file and will access the freed waitqueue when the file is closed or upon exit: fput ep_eventpoll_release ep_free ep_remove_wait_queue remove_wait_queue This results in use-after-free as pasted below. The fundamental problem here is that cgroup_file_release() (and consequently waitqueue's lifetime) is not tied to the file's real lifetime. Using wake_up_pollfree() here might be less than ideal, but it is in line with the comment at commit 42288cb44c4b ("wait: add wake_up_pollfree()") since the waitqueue's lifetime is not tied to file's one and can be considered as another special case. While this would be fixable by somehow making cgroup_file_release() be tied to the fput(), it would require sizable refactoring at cgroups or higher layer which might be more justifiable if we identify more cases like this. BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0 Write of size 4 at addr ffff88810e625328 by task a.out/4404 CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38 Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017 Call Trace: <TASK> dump_stack_lvl+0x73/0xa0 print_report+0x16c/0x4e0 kasan_report+0xc3/0xf0 kasan_check_range+0x2d2/0x310 _raw_spin_lock_irqsave+0x60/0xc0 remove_wait_queue+0x1a/0xa0 ep_free+0x12c/0x170 ep_eventpoll_release+0x26/0x30 __fput+0x202/0x400 task_work_run+0x11d/0x170 do_exit+0x495/0x1130 do_group_exit+0x100/0x100 get_signal+0xd67/0xde0 arch_do_signal_or_restart+0x2a/0x2b0 exit_to_user_mode_prepare+0x94/0x100 syscall_exit_to_user_mode+0x20/0x40 do_syscall_64+0x52/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Allocated by task 4404: kasan_set_track+0x3d/0x60 __kasan_kmalloc+0x85/0x90 psi_trigger_create+0x113/0x3e0 pressure_write+0x146/0x2e0 cgroup_file_write+0x11c/0x250 kernfs_fop_write_iter+0x186/0x220 vfs_write+0x3d8/0x5c0 ksys_write+0x90/0x110 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 4407: kasan_set_track+0x3d/0x60 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x11d/0x170 slab_free_freelist_hook+0x87/0x150 __kmem_cache_free+0xcb/0x180 psi_trigger_destroy+0x2e8/0x310 cgroup_file_release+0x4f/0xb0 kernfs_drain_open_files+0x165/0x1f0 kernfs_drain+0x162/0x1a0 __kernfs_remove+0x1fb/0x310 kernfs_remove_by_name_ns+0x95/0xe0 cgroup_addrm_files+0x67f/0x700 cgroup_destroy_locked+0x283/0x3c0 cgroup_rmdir+0x29/0x100 kernfs_iop_rmdir+0xd1/0x140 vfs_rmdir+0xfe/0x240 do_rmdir+0x13d/0x280 __x64_sys_rmdir+0x2c/0x30 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38","https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe","https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a","https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a","https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5","https://git.kernel.org/stable/c/7caeb5457bd01ccba0df1d6f4872f20d28e50b38","https://git.kernel.org/stable/c/c2dbe32d5db5c4ead121cf86dabd5ab691fb47fe","https://git.kernel.org/stable/c/c6879a4dcefe92d870ab68cabaa9caeda4f2af5a","https://git.kernel.org/stable/c/cca2b3feb70170ef6f0fbc4b4d91eea235a2b73a","https://git.kernel.org/stable/c/ec9c7aa08819f976b2492fa63c41b5712d2924b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52772 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: af_unix: fix use-after-free in unix_stream_read_actor() syzbot reported the following crash [1] After releasing unix socket lock, u->oob_skb can be changed by another thread. We must temporarily increase skb refcount to make sure this other thread will not free the skb under us. [1] BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297 CPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc4/0x620 mm/kasan/report.c:475 kasan_report+0xda/0x110 mm/kasan/report.c:588 unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866 unix_stream_recv_urg net/unix/af_unix.c:2587 [inline] unix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666 unix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg+0xe2/0x170 net/socket.c:1066 ____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803 ___sys_recvmsg+0x115/0x1a0 net/socket.c:2845 __sys_recvmsg+0x114/0x1e0 net/socket.c:2875 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fc67492c559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559 RDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004 RBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340 R13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388 </TASK> Allocated by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523 __alloc_skb+0x287/0x330 net/core/skbuff.c:641 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331 sock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] queue_oob net/unix/af_unix.c:2147 [inline] unix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 5295: kasan_save_stack+0x33/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200 kasan_slab_free include/linux/kasan.h:164 [inline] slab_free_hook mm/slub.c:1800 [inline] slab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826 slab_free mm/slub.c:3809 [inline] kmem_cache_free+0xf8/0x340 mm/slub.c:3831 kfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015 __kfree_skb net/core/skbuff.c:1073 [inline] consume_skb net/core/skbuff.c:1288 [inline] consume_skb+0xdf/0x170 net/core/skbuff.c:1282 queue_oob net/unix/af_unix.c:2178 [inline] u ---truncated--- | ["https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce","https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d","https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef","https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700","https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0","https://git.kernel.org/stable/c/069a3ec329ff43e7869a3d94c62cd03203016bce","https://git.kernel.org/stable/c/4b7b492615cf3017190f55444f7016812b66611d","https://git.kernel.org/stable/c/75bcfc188abf4fae9c1d5f5dc0a03540be602eef","https://git.kernel.org/stable/c/d179189eec426fe4801e4b91efa1889faed12700","https://git.kernel.org/stable/c/eae0b295ce16d8c8b4114c3037993191b4bb92f0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52859 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf: hisi: Fix use-after-free when register pmu fails When we fail to register the uncore pmu, the pmu context may not been allocated. The error handing will call cpuhp_state_remove_instance() to call uncore pmu offline callback, which migrate the pmu context. Since that's liable to lead to some kind of use-after-free. Use cpuhp_state_remove_instance_nocalls() instead of cpuhp_state_remove_instance() so that the notifiers don't execute after the PMU device has been failed to register. | ["https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2","https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda","https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63","https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5","https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735","https://git.kernel.org/stable/c/0e1e88bba286621b886218363de07b319d6208b2","https://git.kernel.org/stable/c/3405f364f82d4f5407a8b4c519dc15d24b847fda","https://git.kernel.org/stable/c/75bab28ffd05ec8879c197890b1bd1dfec8d3f63","https://git.kernel.org/stable/c/b660420f449d094b1fabfa504889810b3a63cdd5","https://git.kernel.org/stable/c/b805cafc604bfdb671fae7347a57f51154afa735"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50128 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: wwan: fix global oob in wwan_rtnl_policy The variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. Exactly same bug cause as the oob fixed in commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"). ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 Read of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862 CPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x14f/0x750 mm/kasan/report.c:395 kasan_report+0x139/0x170 mm/kasan/report.c:495 validate_nla lib/nlattr.c:388 [inline] __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603 __nla_parse+0x3c/0x50 lib/nlattr.c:700 nla_parse_nested_deprecated include/net/netlink.h:1269 [inline] __rtnl_newlink net/core/rtnetlink.c:3514 [inline] rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623 rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122 netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508 netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline] netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352 netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874 sock_sendmsg_nosec net/socket.c:716 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499 ___sys_sendmsg+0x21c/0x290 net/socket.c:2553 __sys_sendmsg net/socket.c:2582 [inline] __do_sys_sendmsg net/socket.c:2591 [inline] __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f67b19a24ad RSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad RDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004 RBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40 </TASK> The buggy address belongs to the variable: wwan_rtnl_policy+0x20/0x40 The buggy address belongs to the physical page: page:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c flags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner info is not present (never set?) Memory state around the buggy address: ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9 ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 >ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 ^ ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== According to the comment of `nla_parse_nested_deprecated`, use correct size `IFLA_WWAN_MAX` here to fix this issue. | ["https://git.kernel.org/stable/c/47dd5447cab8ce30a847a0337d5341ae4c7476a7","https://git.kernel.org/stable/c/69076f8435c1c5dae5f814eaf4c361d1f00b22a3","https://git.kernel.org/stable/c/9683804e36668f6093fb06e202eed2f188ba437e","https://git.kernel.org/stable/c/a3ffce63dcc0c208edd4d196e17baed22ebcb643","https://git.kernel.org/stable/c/c9a0aed51977198df005d0a623090e38e2d77d7b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43884 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Add error handling to pair_device() hci_conn_params_add() never checks for a NULL value and could lead to a NULL pointer dereference causing a crash. Fixed by adding error handling in the function. | ["https://git.kernel.org/stable/c/064dd929c76532359d2905d90a7c12348043cfd4","https://git.kernel.org/stable/c/11b4b0e63f2621b33b2e107407a7d67a65994ca1","https://git.kernel.org/stable/c/538fd3921afac97158d4177139a0ad39f056dbb2","https://git.kernel.org/stable/c/5da2884292329bc9be32a7778e0e119f06abe503","https://git.kernel.org/stable/c/90e1ff1c15e5a8f3023ca8266e3a85869ed03ee9","https://git.kernel.org/stable/c/951d6cb5eaac5130d076c728f2a6db420621afdb","https://git.kernel.org/stable/c/9df9783bd85610d3d6e126a1aca221531f6f6dcb","https://git.kernel.org/stable/c/ee0799103b1ae4bcfd80dc11a15df085f6ee1b61"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41002 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec - Fix memory leak for sec resource release The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs. The aiv resource release is added to the sec resource release function. | ["https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47","https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6","https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601","https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2","https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094","https://git.kernel.org/stable/c/36810d2db3496bb8b4db7ccda666674a5efc7b47","https://git.kernel.org/stable/c/7c42ce556ff65995c8875c9ed64141c14238e7e6","https://git.kernel.org/stable/c/9f21886370db451b0fdc651f6e41550a1da70601","https://git.kernel.org/stable/c/a886bcb0f67d1e3d6b2da25b3519de59098200c2","https://git.kernel.org/stable/c/bba4250757b4ae1680fea435a358d8093f254094"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39463 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: 9p: add missing locking around taking dentry fid list Fix a use-after-free on dentry's d_fsdata fid list when a thread looks up a fid through dentry while another thread unlinks it: UAF thread: refcount_t: addition on 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Freed by: p9_fid_destroy (inlined) p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 The problem is that d_fsdata was not accessed under d_lock, because d_release() normally is only called once the dentry is otherwise no longer accessible but since we also call it explicitly in v9fs_remove that lock is required: move the hlist out of the dentry under lock then unref its fids once they are no longer accessible. | ["https://git.kernel.org/stable/c/3bb6763a8319170c2d41c4232c8e7e4c37dcacfb","https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409","https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456","https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5","https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4","https://www.zerodayinitiative.com/advisories/ZDI-24-1194/","https://git.kernel.org/stable/c/c898afdc15645efb555acb6d85b484eb40a45409","https://git.kernel.org/stable/c/cb299cdba09f46f090b843d78ba26b667d50a456","https://git.kernel.org/stable/c/f0c5c944c6d8614c19e6e9a97fd2011dcd30e8f5","https://git.kernel.org/stable/c/fe17ebf22feb4ad7094d597526d558a49aac92b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26765 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Disable IRQ before init_fn() for nonboot CPUs Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to silence such warnings (and also avoid potential errors due to unexpected interrupts): WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0 a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000 a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000 t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001 s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001 s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8 ra: 90000000047bd56c tlb_init+0x24c/0x528 ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000000 (PPLV0 -PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071000 (LIE=12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198 Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140 9000000006456888 9000000006456880 900000010039f950 0000000000000001 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003 0000000000040000 9000000007930370 0000000002b90000 0000000000000004 9000000006366000 900000000619a140 0000000000000000 0000000000000004 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8 00000000000000b0 0000000000000000 0000000000000000 0000000000071000 ... Call Trace: [<90000000047a4828>] show_stack+0x48/0x1a0 [<9000000005b61874>] dump_stack_lvl+0x84/0xcc [<90000000047f60ac>] __warn+0x8c/0x1e0 [<9000000005b0ab34>] report_bug+0x1b4/0x280 [<9000000005b63110>] do_bp+0x2d0/0x480 [<90000000047a2e20>] handle_bp+0x120/0x1c0 [<90000000048e3334>] rcu_cpu_starting+0x214/0x280 [<90000000047bd568>] tlb_init+0x248/0x528 [<90000000047a4c44>] per_cpu_trap_init+0x124/0x160 [<90000000047a19f4>] cpu_probe+0x494/0xa00 [<90000000047b551c>] start_secondary+0x3c/0xc0 [<9000000005b66134>] smpboot_entry+0x50/0x58 | ["https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a","https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f","https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53","https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464","https://git.kernel.org/stable/c/1001db6c42e4012b55e5ee19405490f23e033b5a","https://git.kernel.org/stable/c/8bf2ca8c60712af288b88ba80f8e4df4573d923f","https://git.kernel.org/stable/c/a262b78dd085dbe9b3c75dc1d9c4cd102b110b53","https://git.kernel.org/stable/c/dffdf7c783ef291eef38a5a0037584fd1a7fa464"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26770 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: nvidia-shield: Add missing null pointer checks to LED initialization devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. [jkosina@suse.com: tweak changelog a bit] | ["https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100","https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183","https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443","https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100","https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183","https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26989 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: hibernate: Fix level3 translation fault in swsusp_save() On arm64 machines, swsusp_save() faults if it attempts to access MEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFI when booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24 The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable() -> kernel_page_present() assuming that a page is always present when can_set_direct_map() is false (all of rodata_full, debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false), irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regions should not be saved during hibernation. This problem was introduced by changes to the pfn_valid() logic in commit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplify pfn_valid()"). Similar to other architectures, drop the !can_set_direct_map() check in kernel_page_present() so that page_is_savable() skips such pages. [catalin.marinas@arm.com: rework commit message] | ["https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3","https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4","https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457","https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069","https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6","https://git.kernel.org/stable/c/022b19ebc31cce369c407617041a3db810db23b3","https://git.kernel.org/stable/c/31f815cb436082e72d34ed2e8a182140a73ebdf4","https://git.kernel.org/stable/c/50449ca66cc5a8cbc64749cf4b9f3d3fc5f4b457","https://git.kernel.org/stable/c/813f5213f2c612dc800054859aaa396ec8ad7069","https://git.kernel.org/stable/c/f7e71a7cf399f53ff9fc314ca3836dc913b05bd6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3649 | High | fixed |
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is the function nilfs_new_inode of the file fs/nilfs2/inode.c of the component BPF. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211992. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20230214-0009/","https://vuldb.com/?id.211992","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d325dc6eb763c10f591c239550b8c7e5466a5d09","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20230214-0009/","https://vuldb.com/?id.211992"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43819 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kvm: s390: Reject memory region operations for ucontrol VMs This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP. Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2. [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix] | ["https://git.kernel.org/stable/c/49c9945c054df4c22008e2bf87ca74d3e2507aa6","https://git.kernel.org/stable/c/7816e58967d0e6cadce05c8540b47ed027dc2499"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Avoid hw_desc array overrun in dw-axi-dmac I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3 segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put() handles the hw_desc considering the descs_allocated, this scenario would result in a kernel panic (hw_desc array will be overrun). To fix this, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in axi_desc_put() to handle the hw_desc array correctly. Additionally I propose to remove the axi_chan_start_first_queued() call after completing the transfer, since it was identified that unbalance can occur (started descriptors can be interrupted and transfer ignored due to DMA channel not being enabled). | ["https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697","https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5","https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe","https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e","https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66","https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697","https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5","https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe","https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e","https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4095 | Medium | N/A | A NULL pointer dereference was found in the Linux kernel's KVM when dirty ring logging is enabled without an active vCPU context. An unprivileged local attacker on the host may use this flaw to cause a kernel oops condition and thus a denial of service by issuing a KVM_XEN_HVM_SET_ATTR ioctl. This flaw affects Linux kernel versions prior to 5.17-rc1. | ["http://www.openwall.com/lists/oss-security/2022/01/17/1","https://bugzilla.redhat.com/show_bug.cgi?id=2031194","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIOQN7JJNN6ABIDGRSTVZA65MHRLMH2Q/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VT6573CGKVK3DU2632VVO5BVM4IU7SBV/","http://www.openwall.com/lists/oss-security/2022/01/17/1","https://bugzilla.redhat.com/show_bug.cgi?id=2031194","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/QIOQN7JJNN6ABIDGRSTVZA65MHRLMH2Q/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VT6573CGKVK3DU2632VVO5BVM4IU7SBV/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35849 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix information leak in btrfs_ioctl_logical_to_ino() Syzbot reported the following information leak for in btrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000 This happens, because we're copying a 'struct btrfs_data_container' back to user-space. This btrfs_data_container is allocated in 'init_data_container()' via kvmalloc(), which does not zero-fill the memory. Fix this by using kvzalloc() which zeroes out the memory on allocation. | ["https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf","https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6","https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc","https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772","https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86","https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6","https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d","https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54","https://git.kernel.org/stable/c/2f7ef5bb4a2f3e481ef05fab946edb97c84f67cf","https://git.kernel.org/stable/c/30189e54ba80e3209d34cfeea87b848f6ae025e6","https://git.kernel.org/stable/c/3a63cee1a5e14a3e52c19142c61dd5fcb524f6dc","https://git.kernel.org/stable/c/689efe22e9b5b7d9d523119a9a5c3c17107a0772","https://git.kernel.org/stable/c/73db209dcd4ae026021234d40cfcb2fb5b564b86","https://git.kernel.org/stable/c/8bdbcfaf3eac42f98e5486b3d7e130fa287811f6","https://git.kernel.org/stable/c/e58047553a4e859dafc8d1d901e1de77c9dd922d","https://git.kernel.org/stable/c/fddc19631c51d9c17d43e9f822a7bc403af88d54","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52741 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix use-after-free in rdata->read_into_pages() When the network status is unstable, use-after-free may occur when read data from the server. BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0 Call Trace: <TASK> dump_stack_lvl+0x38/0x4c print_report+0x16f/0x4a6 kasan_report+0xb7/0x130 readpages_fill_pages+0x14c/0x7e0 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 </TASK> Allocated by task 2535: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x82/0x90 cifs_readdata_direct_alloc+0x2c/0x110 cifs_readdata_alloc+0x2d/0x60 cifs_readahead+0x393/0xfe0 read_pages+0x12f/0x470 page_cache_ra_unbounded+0x1b1/0x240 filemap_get_pages+0x1c8/0x9a0 filemap_read+0x1c0/0x540 cifs_strict_readv+0x21b/0x240 vfs_read+0x395/0x4b0 ksys_read+0xb8/0x150 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 79: kasan_save_stack+0x22/0x50 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2e/0x50 __kasan_slab_free+0x10e/0x1a0 __kmem_cache_free+0x7a/0x1a0 cifs_readdata_release+0x49/0x60 process_one_work+0x46c/0x760 worker_thread+0x2a4/0x6f0 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 Last potentially related work creation: kasan_save_stack+0x22/0x50 __kasan_record_aux_stack+0x95/0xb0 insert_work+0x2b/0x130 __queue_work+0x1fe/0x660 queue_work_on+0x4b/0x60 smb2_readv_callback+0x396/0x800 cifs_abort_connection+0x474/0x6a0 cifs_reconnect+0x5cb/0xa50 cifs_readv_from_socket.cold+0x22/0x6c cifs_read_page_from_socket+0xc1/0x100 readpages_fill_pages.cold+0x2f/0x46 cifs_readv_receive+0x46d/0xa40 cifs_demultiplex_thread+0x121c/0x1490 kthread+0x16b/0x1a0 ret_from_fork+0x2c/0x50 The following function calls will cause UAF of the rdata pointer. readpages_fill_pages cifs_read_page_from_socket cifs_readv_from_socket cifs_reconnect __cifs_reconnect cifs_abort_connection mid->callback() --> smb2_readv_callback queue_work(&rdata->work) # if the worker completes first, # the rdata is freed cifs_readv_complete kref_put cifs_readdata_release kfree(rdata) return rdata->... # UAF in readpages_fill_pages() Similarly, this problem also occurs in the uncache_fill_pages(). Fix this by adjusts the order of condition judgment in the return statement. | ["https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0","https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e","https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211","https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9","https://git.kernel.org/stable/c/2b693fe3f760c87fd9768e759f6297f743a1b3b0","https://git.kernel.org/stable/c/3684a2f6affa1ca52a5d4a12f04d0652efdee65e","https://git.kernel.org/stable/c/aa5465aeca3c66fecdf7efcf554aed79b4c4b211","https://git.kernel.org/stable/c/d1fba1e096ffc7ec11df863a97c50203c47315b9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48858 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix a race on command flush flow Fix a refcount use after free warning due to a race on command entry. Such race occurs when one of the commands releases its last refcount and frees its index and entry while another process running command flush flow takes refcount to this command entry. The process which handles commands flush may see this command as needed to be flushed if the other process released its refcount but didn't release the index yet. Fix it by adding the needed spin lock. It fixes the following warning trace: refcount_t: addition on 0; use-after-free. WARNING: CPU: 11 PID: 540311 at lib/refcount.c:25 refcount_warn_saturate+0x80/0xe0 ... RIP: 0010:refcount_warn_saturate+0x80/0xe0 ... Call Trace: <TASK> mlx5_cmd_trigger_completions+0x293/0x340 [mlx5_core] mlx5_cmd_flush+0x3a/0xf0 [mlx5_core] enter_error_state+0x44/0x80 [mlx5_core] mlx5_fw_fatal_reporter_err_work+0x37/0xe0 [mlx5_core] process_one_work+0x1be/0x390 worker_thread+0x4d/0x3d0 ? rescuer_thread+0x350/0x350 kthread+0x141/0x160 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 </TASK> | ["https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6","https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d","https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee","https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a","https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f","https://git.kernel.org/stable/c/0401bfb27a91d7bdd74b1635c1aae57cbb128da6","https://git.kernel.org/stable/c/063bd355595428750803d8736a9bb7c8db67d42d","https://git.kernel.org/stable/c/1a4017926eeea56c7540cc41b42106746ee8a0ee","https://git.kernel.org/stable/c/7c519f769f555ff7d9d4ccba3497bbb589df360a","https://git.kernel.org/stable/c/f3331bc17449f15832c31823f27573f4c0e13e5f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27407 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fixed overflow check in mi_enum_attr() | ["https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7","https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb","https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08","https://git.kernel.org/stable/c/e99faa97359654b6e4e769246c72cf50a57e05b2","https://git.kernel.org/stable/c/1c0a95d99b1b2b5d842e5abc7ef7eed1193b60d7","https://git.kernel.org/stable/c/652cfeb43d6b9aba5c7c4902bed7a7340df131fb","https://git.kernel.org/stable/c/8c77398c72618101d66480b94b34fe9087ee3d08"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48981 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove errant put in error path drm_gem_shmem_mmap() doesn't own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free. | ["https://git.kernel.org/stable/c/24013314be6ee4ee456114a671e9fa3461323de8","https://git.kernel.org/stable/c/585a07b820059462e0c93b76c7de2cd946b26b40","https://git.kernel.org/stable/c/586847b98e20ab02212ca5c1fc46680384e68a28","https://git.kernel.org/stable/c/6a4da05acd062ae7774b6b19cef2b7d922902d36","https://git.kernel.org/stable/c/83e3da8bb92fcfa7a1d232cf55f9e6c49bb84942"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49025 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free when reverting termination table When having multiple dests with termination tables and second one or afterwards fails the driver reverts usage of term tables but doesn't reset the assignment in attr->dests[num_vport_dests].termtbl which case a use-after-free when releasing the rule. Fix by resetting the assignment of termtbl to null. | ["https://git.kernel.org/stable/c/0a2d73a77060c3cbdc6e801cd5d979d674cd404b","https://git.kernel.org/stable/c/0d2f9d95d9fbe993f3c4bafb87d59897b0325aff","https://git.kernel.org/stable/c/372eb550faa0757349040fd43f59483cbfdb2c0b","https://git.kernel.org/stable/c/52c795af04441d76f565c4634f893e5b553df2ae","https://git.kernel.org/stable/c/e6d2d26a49c3a9cd46b232975e45236304810904"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26610 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix a memory corruption iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in bytes, we'll write past the buffer. | ["https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a","https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b","https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd","https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32","https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d","https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67","https://git.kernel.org/stable/c/05dd9facfb9a1e056752c0901c6e86416037d15a","https://git.kernel.org/stable/c/870171899d75d43e3d14360f3a4850e90a9c289b","https://git.kernel.org/stable/c/99a23462fe1a6f709f0fda3ebbe8b6b193ac75bd","https://git.kernel.org/stable/c/aa2cc9363926991ba74411e3aa0a0ea82c1ffe32","https://git.kernel.org/stable/c/cf4a0d840ecc72fcf16198d5e9c505ab7d5a5e4d","https://git.kernel.org/stable/c/f32a81999d0b8e5ce60afb5f6a3dd7241c17dd67","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49017 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: re-fetch skb cb after tipc_msg_validate As the call trace shows, the original skb was freed in tipc_msg_validate(), and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: <IRQ> tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipc_msg_validate(). | ["https://git.kernel.org/stable/c/1daec0815655e110c6f206c5e777a4af8168ff58","https://git.kernel.org/stable/c/3067bc61fcfe3081bf4807ce65560f499e895e77","https://git.kernel.org/stable/c/a1ba595e35aa3afbe417ff0af353afb9f65559c0","https://git.kernel.org/stable/c/e128190adb2edfd5042105b5d1ed4553f295f5ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49006 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Free buffers when a used dynamic event is removed After 65536 dynamic events have been added and removed, the "type" field of the event then uses the first type number that is available (not currently used by other events). A type number is the identifier of the binary blobs in the tracing ring buffer (known as events) to map them to logic that can parse the binary blob. The issue is that if a dynamic event (like a kprobe event) is traced and is in the ring buffer, and then that event is removed (because it is dynamic, which means it can be created and destroyed), if another dynamic event is created that has the same number that new event's logic on parsing the binary blob will be used. To show how this can be an issue, the following can crash the kernel: # cd /sys/kernel/tracing # for i in `seq 65536`; do echo 'p:kprobes/foo do_sys_openat2 $arg1:u32' > kprobe_events # done For every iteration of the above, the writing to the kprobe_events will remove the old event and create a new one (with the same format) and increase the type number to the next available on until the type number reaches over 65535 which is the max number for the 16 bit type. After it reaches that number, the logic to allocate a new number simply looks for the next available number. When an dynamic event is removed, that number is then available to be reused by the next dynamic event created. That is, once the above reaches the max number, the number assigned to the event in that loop will remain the same. Now that means deleting one dynamic event and created another will reuse the previous events type number. This is where bad things can happen. After the above loop finishes, the kprobes/foo event which reads the do_sys_openat2 function call's first parameter as an integer. # echo 1 > kprobes/foo/enable # cat /etc/passwd > /dev/null # cat trace cat-2211 [005] .... 2007.849603: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849620: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849838: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 cat-2211 [005] .... 2007.849880: foo: (do_sys_openat2+0x0/0x130) arg1=4294967196 # echo 0 > kprobes/foo/enable Now if we delete the kprobe and create a new one that reads a string: # echo 'p:kprobes/foo do_sys_openat2 +0($arg2):string' > kprobe_events And now we can the trace: # cat trace sendmail-1942 [002] ..... 530.136320: foo: (do_sys_openat2+0x0/0x240) arg1= cat-2046 [004] ..... 530.930817: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.930961: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934278: foo: (do_sys_openat2+0x0/0x240) arg1="������������������������������������������������������������������������������������������������" cat-2046 [004] ..... 530.934563: foo: (do_sys_openat2+0x0/0x240) arg1="��������������������������������������� ---truncated--- | ["https://git.kernel.org/stable/c/1603feac154ff38514e8354e3079a455eb4801e2","https://git.kernel.org/stable/c/417d5ea6e735e5d88ffb6c436cf2938f3f476dd1","https://git.kernel.org/stable/c/4313e5a613049dfc1819a6dfb5f94cf2caff9452","https://git.kernel.org/stable/c/be111ebd8868d4b7c041cb3c6102e1ae27d6dc1d","https://git.kernel.org/stable/c/c52d0c8c4f38f7580cff61c4dfe1034c580cedfd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48892 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/core: Fix use-after-free bug in dup_user_cpus_ptr() Since commit 07ec77a1d4e8 ("sched: Allow task CPU affinity to be restricted on asymmetric systems"), the setting and clearing of user_cpus_ptr are done under pi_lock for arm64 architecture. However, dup_user_cpus_ptr() accesses user_cpus_ptr without any lock protection. Since sched_setaffinity() can be invoked from another process, the process being modified may be undergoing fork() at the same time. When racing with the clearing of user_cpus_ptr in __set_cpus_allowed_ptr_locked(), it can lead to user-after-free and possibly double-free in arm64 kernel. Commit 8f9ea86fdf99 ("sched: Always preserve the user requested cpumask") fixes this problem as user_cpus_ptr, once set, will never be cleared in a task's lifetime. However, this bug was re-introduced in commit 851a723e45d1 ("sched: Always clear user_cpus_ptr in do_set_cpus_allowed()") which allows the clearing of user_cpus_ptr in do_set_cpus_allowed(). This time, it will affect all arches. Fix this bug by always clearing the user_cpus_ptr of the newly cloned/forked task before the copying process starts and check the user_cpus_ptr state of the source task under pi_lock. Note to stable, this patch won't be applicable to stable releases. Just copy the new dup_user_cpus_ptr() function over. | ["https://git.kernel.org/stable/c/7b5cc7fd1789ea5dbb942c9f8207b076d365badc","https://git.kernel.org/stable/c/87ca4f9efbd7cc649ff43b87970888f2812945b8","https://git.kernel.org/stable/c/b22faa21b6230d5eccd233e1b7e0026a5002b287"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53025 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: fix use-after-free in nfsd4_ssc_setup_dul() If signal_pending() returns true, schedule_timeout() will not be executed, causing the waiting task to remain in the wait queue. Fixed by adding a call to finish_wait(), which ensures that the waiting task will always be removed from the wait queue. | ["https://git.kernel.org/stable/c/0a27dcd5343026ac0cb168ee63304255372b7a36","https://git.kernel.org/stable/c/32d5eb95f8f0e362e37c393310b13b9e95404560","https://git.kernel.org/stable/c/6ac4c383c39f8f2f955f868d1ad9365c2363e80b","https://git.kernel.org/stable/c/e6cf91b7b47ff82b624bdfe2fdcde32bb52e71dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26944 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free in do_zone_finish() Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: <TASK> dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish(). The sequence of events is as follows: btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freed cleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed device The reason for this is that we're using a ---truncated--- | ["https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302","https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57","https://git.kernel.org/stable/c/1ec17ef59168a1a6f1105f5dc517f783839a5302","https://git.kernel.org/stable/c/34ca809e055eca5cfe63d9c7efbf80b7c21b4e57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26933 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in port "disable" sysfs attribute The show and store callback routines for the "disable" sysfs attribute file in port.c acquire the device lock for the port's parent hub device. This can cause problems if another process has locked the hub to remove it or change its configuration: Removing the hub or changing its configuration requires the hub interface to be removed, which requires the port device to be removed, and device_del() waits until all outstanding sysfs attribute callbacks for the ports have returned. The lock can't be released until then. But the disable_show() or disable_store() routine can't return until after it has acquired the lock. The resulting deadlock can be avoided by calling sysfs_break_active_protection(). This will cause the sysfs core not to wait for the attribute's callback routine to return, allowing the removal to proceed. The disadvantage is that after making this call, there is no guarantee that the hub structure won't be deallocated at any moment. To prevent this, we have to acquire a reference to it first by calling hub_get(). | ["https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7","https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e","https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05","https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1","https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c","https://git.kernel.org/stable/c/4facc9421117ba9d8148c73771b213887fec77f7","https://git.kernel.org/stable/c/73d1589b91f2099e5f6534a8497b7c6b527e064e","https://git.kernel.org/stable/c/9dac54f08198147f5ec0ec52fcf1bc8ac899ac05","https://git.kernel.org/stable/c/f4d1960764d8a70318b02f15203a1be2b2554ca1","https://git.kernel.org/stable/c/f51849833705dea5b4f9b0c8de714dd87bd6c95c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26736 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: afs: Increase buffer size in afs_update_volume_status() The max length of volume->vid value is 20 characters. So increase idbuf[] size up to 24 to avoid overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. [DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()] | ["https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5","https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e","https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d","https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa","https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637","https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e","https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1","https://git.kernel.org/stable/c/5c27d85a69fa16a08813ba37ddfb4bbc9a1ed6b5","https://git.kernel.org/stable/c/6e6065dd25b661420fac19c34282b6c626fcd35e","https://git.kernel.org/stable/c/6ea38e2aeb72349cad50e38899b0ba6fbcb2af3d","https://git.kernel.org/stable/c/d34a5e57632bb5ff825196ddd9a48ca403626dfa","https://git.kernel.org/stable/c/d9b5e2b7a8196850383c70d099bfd39e81ab6637","https://git.kernel.org/stable/c/e56662160fc24d28cb75ac095cc6415ae1bda43e","https://git.kernel.org/stable/c/e8530b170e464017203e3b8c6c49af6e916aece1","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50244 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process. | ["https://git.kernel.org/stable/c/14a23e15a5e8331bb0cf21288723fa530a45b2a4","https://git.kernel.org/stable/c/60fb94ef46c2359dd06cbe30bfc2499f639433df","https://git.kernel.org/stable/c/7a4ace681dbb652aeb40e1b88f9134b880fdeeb5","https://git.kernel.org/stable/c/80824967ec714dda02cd79091aa186bbc16c5cf3","https://git.kernel.org/stable/c/d178944db36b3369b78a08ba520de109b89bf2a9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50067 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: uprobe: avoid out-of-bounds memory access of fetching args Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem. Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access. It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c ``` \#include <stdio.h> \#include <stdlib.h> \#include <string.h> // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093 void generate_string(char *str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; } void print_string(char *str) { printf("%s\n", str); } int main() { char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0; } ``` 3. compile program `gcc -o test test.c` 4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g F .text 000000000000001b print_string ``` 5. configure uprobe with offset 0x1199 ``` off=0x1199 cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_events echo 1 > events/uprobes/enable echo 1 > tracing_on ``` 6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK> This commit enforces the buffer's maxlen less than a page-size to avoid store_trace_args() out-of-memory access. | ["https://git.kernel.org/stable/c/0dc3ad9ad2188da7f090b3dbe4d2fcd9ae8ae64f","https://git.kernel.org/stable/c/373b9338c9722a368925d83bc622c596896b328e","https://git.kernel.org/stable/c/537ad4a431f6dddbf15d40d19f24bb9ee12b55cb","https://git.kernel.org/stable/c/9e5f93788c9dd4309e75a56860a1ac44a8e117b9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49996 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev(). | ["https://git.kernel.org/stable/c/01cdddde39b065074fd48f07027757783cbf5b7d","https://git.kernel.org/stable/c/73b078e3314d4854fd8286f3ba65c860ddd3a3dd","https://git.kernel.org/stable/c/7b222d6cb87077faf56a687a72af1951cf78c8a9","https://git.kernel.org/stable/c/803b3a39cb096d8718c0aebc03fd19f11c7dc919","https://git.kernel.org/stable/c/c173d47b69f07cd7ca08efb4e458adbd4725d8e9","https://git.kernel.org/stable/c/c6db81c550cea0c73bd72ef55f579991e0e4ba07","https://git.kernel.org/stable/c/e2a8910af01653c1c268984855629d71fb81f404","https://git.kernel.org/stable/c/ec79e6170bcae8a6036a4b6960f5e7e59a785601"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3564 | High | fixed |
|
A vulnerability classified as critical was found in Linux Kernel. Affected by this vulnerability is the function l2cap_reassemble_sdu of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211087. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20221223-0001/","https://vuldb.com/?id.211087","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://security.netapp.com/advisory/ntap-20221223-0001/","https://vuldb.com/?id.211087"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36955 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node() The documentation for device_get_named_child_node() mentions this important point: " The caller is responsible for calling fwnode_handle_put() on the returned fwnode pointer. " Add fwnode_handle_put() to avoid a leaked reference. | ["https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e","https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf","https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07","https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377","https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a","https://git.kernel.org/stable/c/722d33c442e66e4aabd3e778958d696ff3a2777e","https://git.kernel.org/stable/c/7db626d2730d3d80fd31638169054b1e507f07bf","https://git.kernel.org/stable/c/7ef6ecf98ce309b1f4e5a25cddd5965d01feea07","https://git.kernel.org/stable/c/bd2d9641a39e6b5244230c4b41c4aca83b54b377","https://git.kernel.org/stable/c/c158cf914713efc3bcdc25680c7156c48c12ef6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48666 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix a use-after-free There are two .exit_cmd_priv implementations. Both implementations use resources associated with the SCSI host. Make sure that these resources are still available when .exit_cmd_priv is called by waiting inside scsi_remove_host() until the tag set has been freed. This commit fixes the following use-after-free: ================================================================== BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp] Read of size 8 at addr ffff888100337000 by task multipathd/16727 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ["https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a","https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f","https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506","https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9","https://git.kernel.org/stable/c/2e7eb4c1e8af8385de22775bd0be552f59b28c9a","https://git.kernel.org/stable/c/5ce8fad941233e81f2afb5b52a3fcddd3ba8732f","https://git.kernel.org/stable/c/8fe4ce5836e932f5766317cb651c1ff2a4cd0506","https://git.kernel.org/stable/c/f818708eeeae793e12dc39f8984ed7732048a7d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-25744 | High | fixed |
|
In the Linux kernel before 6.6.7, an untrusted VMM can trigger int80 syscall handling at any given point. This is related to arch/x86/coco/tdx/tdx.c and arch/x86/mm/mem_encrypt_amd.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b82a8dbd3d2f4563156f7150c6f2ecab6e960b30","https://security.netapp.com/advisory/ntap-20241115-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36478 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues' Writing 'power' and 'submit_queues' concurrently will trigger kernel panic: Test script: modprobe null_blk nr_devices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submit_queues; echo 4 > submit_queues; done & while true; do echo 1 > power; echo 0 > power; done Test result: BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:__lock_acquire+0x41d/0x28f0 Call Trace: <TASK> lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150 This is because del_gendisk() can concurrent with blk_mq_update_nr_hw_queues(): nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULL Fix this problem by resuing the global mutex to protect nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs. | ["https://git.kernel.org/stable/c/1d4c8baef435c98e8d5aa7027dc5a9f70834ba16","https://git.kernel.org/stable/c/5d0495473ee4c1d041b5a917f10446a22c047f47","https://git.kernel.org/stable/c/a2db328b0839312c169eb42746ec46fc1ab53ed2","https://git.kernel.org/stable/c/aaadb755f2d684f715a6eb85cb7243aa0c67dfa9","https://git.kernel.org/stable/c/5d0495473ee4c1d041b5a917f10446a22c047f47","https://git.kernel.org/stable/c/a2db328b0839312c169eb42746ec46fc1ab53ed2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48851 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: gdm724x: fix use after free in gdm_lte_rx() The netif_rx_ni() function frees the skb so we can't dereference it to save the skb->len. | ["https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f","https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff","https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169","https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757","https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a","https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a","https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5","https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033","https://git.kernel.org/stable/c/1fb9dd3787495b4deb0efe66c58306b65691a48f","https://git.kernel.org/stable/c/403e3afe241b62401de1f8629c9c6b9b3d69dbff","https://git.kernel.org/stable/c/48ecdf3e29a6e514e8196691589c7dfc6c4ac169","https://git.kernel.org/stable/c/6d9700b445098dbbce0caff4b8cfca214cf1e757","https://git.kernel.org/stable/c/6dc7b87c62423bfa68139fe95e85028aab584c9a","https://git.kernel.org/stable/c/83a9c886c2b5a0d28c0b37e1736b47f38d61332a","https://git.kernel.org/stable/c/d39dc79513e99147b4c158a8a9e46743e23944f5","https://git.kernel.org/stable/c/fc7f750dc9d102c1ed7bbe4591f991e770c99033"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4206 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_route component can be exploited to achieve local privilege escalation. When route4_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://kernel.dance/b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46746 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: free driver_data after destroying hid device HID driver callbacks aren't called anymore once hid_destroy_device() has been called. Hence, hid driver_data should be freed only after the hid_destroy_device() function returned as driver_data is used in several callbacks. I observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling KASAN to debug memory allocation, I got this output: [ 13.050438] ================================================================== [ 13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh] [ 13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3 [ 13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479 [ 13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0 [ 13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024 [ 13.067860] Call Trace: [ 13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8 [ 13.071486] <TASK> [ 13.071492] dump_stack_lvl+0x5d/0x80 [ 13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002) [ 13.078296] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.082199] print_report+0x174/0x505 [ 13.085776] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 13.089367] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.093255] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.097464] kasan_report+0xc8/0x150 [ 13.101461] ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.105802] amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.110303] amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38] [ 13.114879] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.119450] sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082] [ 13.124097] hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.127404] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.131925] ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5] [ 13.136455] ? _raw_spin_lock_irqsave+0x96/0xf0 [ 13.140197] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 13.143602] ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b] [ 13.147234] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.150446] ? __devm_add_action+0x167/0x1d0 [ 13.155061] hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.158581] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.161814] platform_probe+0xa2/0x150 [ 13.165029] really_probe+0x1e3/0x8a0 [ 13.168243] __driver_probe_device+0x18c/0x370 [ 13.171500] driver_probe_device+0x4a/0x120 [ 13.175000] __driver_attach+0x190/0x4a0 [ 13.178521] ? __pfx___driver_attach+0x10/0x10 [ 13.181771] bus_for_each_dev+0x106/0x180 [ 13.185033] ? __pfx__raw_spin_lock+0x10/0x10 [ 13.188229] ? __pfx_bus_for_each_dev+0x10/0x10 [ 13.191446] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.194382] bus_add_driver+0x29e/0x4d0 [ 13.197328] driver_register+0x1a5/0x360 [ 13.200283] ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172] [ 13.203362] do_one_initcall+0xa7/0x380 [ 13.206432] ? __pfx_do_one_initcall+0x10/0x10 [ 13.210175] ? srso_alias_return_thunk+0x5/0xfbef5 [ 13.213211] ? kasan_unpoison+0x44/0x70 [ 13.216688] do_init_module+0x238/0x750 [ 13.2196 ---truncated--- | ["https://git.kernel.org/stable/c/60dc4ee0428d70bcbb41436b6729d29f1cbdfb89","https://git.kernel.org/stable/c/775125c7fe38533aaa4b20769f5b5e62cc1170a0","https://git.kernel.org/stable/c/86b4f5cf91ca03c08e3822ac89476a677a780bcc","https://git.kernel.org/stable/c/97155021ae17b86985121b33cf8098bcde00d497","https://git.kernel.org/stable/c/adb3e3c1ddb5a23b8b7122ef1913f528d728937c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52930 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential bit_17 double-free A userspace with multiple threads racing I915_GEM_SET_TILING to set the tiling to I915_TILING_NONE could trigger a double free of the bit_17 bitmask. (Or conversely leak memory on the transition to tiled.) Move allocation/free'ing of the bitmask within the section protected by the obj lock. [tursulin: Correct fixes tag and added cc stable.] (cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e) | ["https://git.kernel.org/stable/c/0769f997a7b6d5cb8336db0b4ec3d2d311b8097c","https://git.kernel.org/stable/c/7057a8f126f14f14b040faecfa220fd27c6c2f85","https://git.kernel.org/stable/c/b591abac78e25269b12e3d7170c99463f8c5cb02","https://git.kernel.org/stable/c/e3ebc3e23bd9028a8a9a26cbc5985f99be445f65"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49992 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/ | ["https://git.kernel.org/stable/c/0a1741d10da29aa84955ef89ae9a03c4b6038657","https://git.kernel.org/stable/c/19dd9780b7ac673be95bf6fd6892a184c9db611f","https://git.kernel.org/stable/c/454e5d7e671946698af0f201e48469e5ddb42851","https://git.kernel.org/stable/c/b22eec4b57d04befa90e8554ede34e6c67257606","https://git.kernel.org/stable/c/d02611ff001454358be6910cb926799e2d818716"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48950 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf: Fix perf_pending_task() UaF Per syzbot it is possible for perf_pending_task() to run after the event is free()'d. There are two related but distinct cases: - the task_work was already queued before destroying the event; - destroying the event itself queues the task_work. The first cannot be solved using task_work_cancel() since perf_release() itself might be called from a task_work (____fput), which means the current->task_works list is already empty and task_work_cancel() won't be able to find the perf_pending_task() entry. The simplest alternative is extending the perf_event lifetime to cover the task_work. The second is just silly, queueing a task_work while you know the event is going away makes no sense and is easily avoided by re-arranging how the event is marked STATE_DEAD and ensuring it goes through STATE_OFF on the way down. | ["https://git.kernel.org/stable/c/517e6a301f34613bff24a8e35b5455884f2d83d8","https://git.kernel.org/stable/c/78e1317a174edbfd1182599bf76c092a2877672c","https://git.kernel.org/stable/c/8bffa95ac19ff27c8261904f89d36c7fcf215d59"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53063 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues. | ["https://git.kernel.org/stable/c/1e461672616b726f29261ee81bb991528818537c","https://git.kernel.org/stable/c/3b88675e18b6517043a6f734eaa8ea6eb3bfa140","https://git.kernel.org/stable/c/5f76f7df14861e3a560898fa41979ec92424b58f","https://git.kernel.org/stable/c/972e63e895abbe8aa1ccbdbb4e6362abda7cd457","https://git.kernel.org/stable/c/9c17085fabbde2041c893d29599800f2d4992b23","https://git.kernel.org/stable/c/a4a17210c03ade1c8d9a9f193a105654b7a05c11","https://git.kernel.org/stable/c/b751a96025275c17f04083cbfe856822f1658946","https://git.kernel.org/stable/c/fedfde9deb83ac8d2f3d5f36f111023df34b1684"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36016 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: fix possible out-of-bounds in gsm0_receive() Assuming the following: - side A configures the n_gsm in basic option mode - side B sends the header of a basic option mode frame with data length 1 - side A switches to advanced option mode - side B sends 2 data bytes which exceeds gsm->len Reason: gsm->len is not used in advanced option mode. - side A switches to basic option mode - side B keeps sending until gsm0_receive() writes past gsm->buf Reason: Neither gsm->state nor gsm->len have been reset after reconfiguration. Fix this by changing gsm->count to gsm->len comparison from equal to less than. Also add upper limit checks against the constant MAX_MRU in gsm0_receive() and gsm1_receive() to harden against memory corruption of gsm->len and gsm->mru. All other checks remain as we still need to limit the data according to the user configuration and actual payload size. | ["https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04","https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc","https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a","https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54","https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350","https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5","https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56","https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d","https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3","https://git.kernel.org/stable/c/0fb736c9931e02dbc7d9a75044c8e1c039e50f04","https://git.kernel.org/stable/c/46f52c89a7e7d2691b97a9728e4591d071ca8abc","https://git.kernel.org/stable/c/47388e807f85948eefc403a8a5fdc5b406a65d5a","https://git.kernel.org/stable/c/4c267110fc110390704cc065edb9817fdd10ff54","https://git.kernel.org/stable/c/774d83b008eccb1c48c14dc5486e7aa255731350","https://git.kernel.org/stable/c/9513d4148950b05bc99fa7314dc883cc0e1605e5","https://git.kernel.org/stable/c/b229bc6c6ea9fe459fc3fa94fd0a27a2f32aca56","https://git.kernel.org/stable/c/b890d45aaf02b564e6cae2d2a590f9649330857d","https://git.kernel.org/stable/c/f126ce7305fe88f49cdabc6db4168b9318898ea3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44983 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate vlan header Ensure there is sufficient room to access the protocol field of the VLAN header, validate it once before the flowtable lookup. ===================================================== BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline] | ["https://git.kernel.org/stable/c/0279c35d242d037abeb73d60d06a6d1bb7f672d9","https://git.kernel.org/stable/c/043a18bb6cf16adaa2f8642acfde6e8956a9caaa","https://git.kernel.org/stable/c/6ea14ccb60c8ab829349979b22b58a941ec4a3ee","https://git.kernel.org/stable/c/c05155cc455785916164aa5e1b4605a2ae946537","https://git.kernel.org/stable/c/d9384ae7aec46036d248d1c2c2757e471ab486c3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46732 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Assign linear_pitch_alignment even for VM [Description] Assign linear_pitch_alignment so we don't cause a divide by 0 error in VM environments | ["https://git.kernel.org/stable/c/4bd7710f2fecfc5fb2dda1ca2adc69db8a66b8b6","https://git.kernel.org/stable/c/984debc133efa05e62f5aa1a7a1dd8ca0ef041f4","https://git.kernel.org/stable/c/c44b568931d23aed9d37ecbb31fb5fbdd198bf7b","https://git.kernel.org/stable/c/d219f902b16d42f0cb8c499ea8f31cf3c0f36349","https://git.kernel.org/stable/c/d2fe7ac613a1ea8c346c9f5c89dc6ecc27232997"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40967 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: imx: Introduce timeout when waiting on transmitter empty By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential deadlock. In case of the timeout, there is not much we can do, so we simply ignore the transmitter state and optimistically try to continue. | ["https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701","https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7","https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916","https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44","https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2","https://git.kernel.org/stable/c/53b2c95547427c358f45515a9f144efee95e3701","https://git.kernel.org/stable/c/7f2b9ab6d0b26f16cd38dd9fd91d51899635f7c7","https://git.kernel.org/stable/c/7f9e70c68b7ace0141fe3bc94bf7b61296b71916","https://git.kernel.org/stable/c/982ae3376c4c91590d38dc8a676c10f7df048a44","https://git.kernel.org/stable/c/e533e4c62e9993e62e947ae9bbec34e4c7ae81c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43854 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: initialize integrity buffer to zero before writing it to media Metadata added by bio_integrity_prep is using plain kmalloc, which leads to random kernel memory being written media. For PI metadata this is limited to the app tag that isn't used by kernel generated metadata, but for non-PI metadata the entire buffer leaks kernel memory. Fix this by adding the __GFP_ZERO flag to allocations for writes. | ["https://git.kernel.org/stable/c/129f95948a96105c1fad8e612c9097763e88ac5f","https://git.kernel.org/stable/c/23a19655fb56f241e592041156dfb1c6d04da644","https://git.kernel.org/stable/c/3fd11fe4f20756b4c0847f755a64cd96f8c6a005","https://git.kernel.org/stable/c/899ee2c3829c5ac14bfc7d3c4a5846c0b709b78f","https://git.kernel.org/stable/c/9f4af4cf08f9a0329ade3d938f55d2220c40d0a6","https://git.kernel.org/stable/c/cf6b45ea7a8df0f61bded1dc4a8561ac6ad143d2","https://git.kernel.org/stable/c/d418313bd8f55c079a7da12651951b489a638ac1","https://git.kernel.org/stable/c/ebc0e91ba76dc6544fff9f5b66408b1982806a00"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45028 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_test: Fix NULL dereference on allocation failure If the "test->highmem = alloc_pages()" allocation fails then calling __free_pages(test->highmem) will result in a NULL dereference. Also change the error code to -ENOMEM instead of returning success. | ["https://git.kernel.org/stable/c/2b507b03991f44dfb202fc2a82c9874d1b1f0c06","https://git.kernel.org/stable/c/3b4e76ceae5b5a46c968bd952f551ce173809f63","https://git.kernel.org/stable/c/9b9ba386d7bfdbc38445932c90fa9444c0524bea","https://git.kernel.org/stable/c/a1e627af32ed60713941cbfc8075d44cad07f6dd","https://git.kernel.org/stable/c/cac2815f49d343b2f0acc4973d2c14918ac3ab0c","https://git.kernel.org/stable/c/e40515582141a9e7c84b269be699c05236a499a6","https://git.kernel.org/stable/c/e97be13a9f51284da450dd2a592e3fa87b49cdc9","https://git.kernel.org/stable/c/ecb15b8ca12c0cbdab81e307e9795214d8b90890"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46685 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review. | ["https://git.kernel.org/stable/c/0a2bab5ed161318f57134716accba0a30f3af191","https://git.kernel.org/stable/c/1c38a62f15e595346a1106025722869e87ffe044","https://git.kernel.org/stable/c/292151af6add3e5ab11b2e9916cffa5f52859a1f","https://git.kernel.org/stable/c/2cea369a5c2e85ab14ae716da1d1cc6d25c85e11","https://git.kernel.org/stable/c/4e9436375fcc9bd2a60ee96aba6ed53f7a377d10","https://git.kernel.org/stable/c/4ed45fe99ec9e3c9478bd634624cd05a57d002f7","https://git.kernel.org/stable/c/6341c2856785dca7006820b127278058a180c075","https://git.kernel.org/stable/c/8f0bd526921b6867c2f10a83cd4fd14139adcd92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49030 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: libbpf: Handle size overflow for ringbuf mmap The maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entries will overflow u32 when mapping producer page and data pages. Only casting max_entries to size_t is not enough, because for 32-bits application on 64-bits kernel the size of read-only mmap region also could overflow size_t. So fixing it by casting the size of read-only mmap region into a __u64 and checking whether or not there will be overflow during mmap. | ["https://git.kernel.org/stable/c/0140e079a42064680394fff1199a7b5483688dec","https://git.kernel.org/stable/c/535a25ab4f9a45f74ba38ab71de95e97474922ed","https://git.kernel.org/stable/c/8a549ab6724520aa3c07f47e0eba820293551490","https://git.kernel.org/stable/c/927cbb478adf917e0a142b94baa37f06279cc466"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26945 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix nr_cpus < nr_iaa case If nr_cpus < nr_iaa, the calculated cpus_per_iaa will be 0, which causes a divide-by-0 in rebalance_wq_table(). Make sure cpus_per_iaa is 1 in that case, and also in the nr_iaa == 0 case, even though cpus_per_iaa is never used if nr_iaa == 0, for paranoia. | ["https://git.kernel.org/stable/c/5a7e89d3315d1be86aff8a8bf849023cda6547f7","https://git.kernel.org/stable/c/a5ca1be7f9817de4e93085778b3ee2219bdc2664","https://git.kernel.org/stable/c/5a7e89d3315d1be86aff8a8bf849023cda6547f7","https://git.kernel.org/stable/c/a5ca1be7f9817de4e93085778b3ee2219bdc2664"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42247 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wireguard: allowedips: avoid unaligned 64-bit memory accesses On the parisc platform, the kernel issues kernel warnings because swap_endian() tries to load a 128-bit IPv6 address from an unaligned memory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc) Avoid such unaligned memory accesses by instead using the get_unaligned_be64() helper macro. [Jason: replace src[8] in original patch with src+8] | ["https://git.kernel.org/stable/c/217978a29c6ceca76d3c640bf94bdf50c268d801","https://git.kernel.org/stable/c/2fb34bf76431e831f9863cd59adc0bd1f67b0fbf","https://git.kernel.org/stable/c/6638a203abad35fa636d59ac47bdbc4bc100fd74","https://git.kernel.org/stable/c/948f991c62a4018fb81d85804eeab3029c6209f8","https://git.kernel.org/stable/c/ae630de24efb123d7199a43256396d7758f4cb75","https://git.kernel.org/stable/c/b4764f0ad3d68de8a0b847c05f427afb86dd54e6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-23307 | High | fixed |
|
Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow. | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=7975","https://bugzilla.openanolis.cn/show_bug.cgi?id=7975"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39301 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/9p: fix uninit-value in p9_client_rpc() Syzbot with the help of KMSAN reported the following error: BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 trace_9p_client_res include/trace/events/9p.h:146 [inline] p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2175 [inline] allocate_slab mm/slub.c:2338 [inline] new_slab+0x2de/0x1400 mm/slub.c:2391 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 __slab_alloc mm/slub.c:3610 [inline] __slab_alloc_node mm/slub.c:3663 [inline] slab_alloc_node mm/slub.c:3835 [inline] kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 p9_tag_alloc net/9p/client.c:278 [inline] p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 legacy_get_tree+0x114/0x290 fs/fs_context.c:662 vfs_get_tree+0xa7/0x570 fs/super.c:1797 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 path_mount+0x742/0x1f20 fs/namespace.c:3679 do_mount fs/namespace.c:3692 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x725/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag will not be properly initialized. However, trace_9p_client_res() ends up trying to print it out anyway before p9_client_rpc() finishes. Fix this issue by assigning default values to p9_fcall fields such as 'tag' and (just in case KMSAN unearths something new) 'id' during the tag allocation stage. | ["https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17","https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b","https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a","https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17","https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867","https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b","https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672","https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163","https://git.kernel.org/stable/c/124947855564572713d705a13be7d0c9dae16a17","https://git.kernel.org/stable/c/2101901dd58c6da4924bc5efb217a1d83436290b","https://git.kernel.org/stable/c/25460d6f39024cc3b8241b14c7ccf0d6f11a736a","https://git.kernel.org/stable/c/6c1791130b781c843572fb6391c4a4c5d857ab17","https://git.kernel.org/stable/c/72c5d8e416ecc46af370a1340b3db5ff0b0cc867","https://git.kernel.org/stable/c/89969ffbeb948ffc159d19252e7469490103011b","https://git.kernel.org/stable/c/ca71f204711ad24113e8b344dc5bb8b0385f5672","https://git.kernel.org/stable/c/fe5c604053c36c62af24eee8a76407d026ea5163"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43839 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. | ["https://git.kernel.org/stable/c/6ce46045f9b90d952602e2c0b8886cfadf860bf1","https://git.kernel.org/stable/c/6d20c4044ab4d0e6a99aa35853e66f0aed5589e3","https://git.kernel.org/stable/c/ab748dd10d8742561f2980fea08ffb4f0cacfdef","https://git.kernel.org/stable/c/b0ff0cd0847b03c0a0abe20cfa900eabcfcb9e43","https://git.kernel.org/stable/c/c90b1cd7758fd4839909e838ae195d19f8065d76","https://git.kernel.org/stable/c/c9741a03dc8e491e57b95fba0058ab46b7e506da","https://git.kernel.org/stable/c/e0f48f51d55fb187400e9787192eda09fa200ff5","https://git.kernel.org/stable/c/f121740f69eda4da2de9a20a6687a13593e72540"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47646 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Revert "Revert "block, bfq: honor already-setup queue merges"" A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset last_bfqq_created on group change"). So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 | ["https://git.kernel.org/stable/c/15729ff8143f8135b03988a100a19e66d7cb7ecd","https://git.kernel.org/stable/c/4083925bd6dc89216d156474a8076feec904e607","https://git.kernel.org/stable/c/65d8a737452e88f251fe5d925371de6d606df613","https://git.kernel.org/stable/c/931aff627469a75c77b9fd3823146d0575afffd6","https://git.kernel.org/stable/c/abc2129e646af7b43025d90a071f83043f1ae76c","https://git.kernel.org/stable/c/cc051f497eac9d8a0d816cd4bffa3415f2724871","https://git.kernel.org/stable/c/f990f0985eda59d4f29fc83fcf300c92b1225d39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49078 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: lz4: fix LZ4_decompress_safe_partial read out of bound When partialDecoding, it is EOF if we've either filled the output buffer or can't proceed with reading an offset for following match. In some extreme corner cases when compressed data is suitably corrupted, UAF will occur. As reported by KASAN [1], LZ4_decompress_safe_partial may lead to read out of bound problem during decoding. lz4 upstream has fixed it [2] and this issue has been disscussed here [3] before. current decompression routine was ported from lz4 v1.8.3, bumping lib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd better fix it first. [1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/ [2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad# [3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/ | ["https://git.kernel.org/stable/c/467d5e200ab4486b744fe1776154a43d1aa22d4b","https://git.kernel.org/stable/c/6adc01a7aa37445dafe8846faa0610a86029b253","https://git.kernel.org/stable/c/73953dfa9d50e5c9fe98ee13fd1d3427aa12a0a3","https://git.kernel.org/stable/c/9fb8bc6cfc58773ce95414e11c9ccc8fc6ac4927","https://git.kernel.org/stable/c/e64dbe97c05c769525cbca099ddbd22485630235","https://git.kernel.org/stable/c/eafc0a02391b7b36617b36c97c4b5d6832cf5e24"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49385 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: driver: base: fix UAF when driver_attach failed When driver_attach(drv); failed, the driver_private will be freed. But it has been added to the bus, which caused a UAF. To fix it, we need to delete it from the bus when failed. | ["https://git.kernel.org/stable/c/310862e574001a97ad02272bac0fd13f75f42a27","https://git.kernel.org/stable/c/5389101257828d1913d713d9a40acbe14f5961df","https://git.kernel.org/stable/c/5d709f58c743166fe1c6914b9de0ae8868600d9b","https://git.kernel.org/stable/c/823f24f2e329babd0330200d0b74882516fe57f4","https://git.kernel.org/stable/c/c059665c84feab46b7173d3a1bf36c2fb7f9df86","https://git.kernel.org/stable/c/cdf1a683a01583bca4b618dd16223cbd6e462e21"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49411 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bfq: Make sure bfqg for which we are queueing requests is online Bios queued into BFQ IO scheduler can be associated with a cgroup that was already offlined. This may then cause insertion of this bfq_group into a service tree. But this bfq_group will get freed as soon as last bio associated with it is completed leading to use after free issues for service tree users. Fix the problem by making sure we always operate on online bfq_group. If the bfq_group associated with the bio is not online, we pick the first online parent. | ["https://git.kernel.org/stable/c/075a53b78b815301f8d3dd1ee2cd99554e34f0dd","https://git.kernel.org/stable/c/51f724bffa3403a5236597e6b75df7329c1ec6e9","https://git.kernel.org/stable/c/6ee0868b0c3ccead5907685fcdcdd0c08dfe4b0b","https://git.kernel.org/stable/c/7781c38552e6cc54ed8e9040279561340516b881","https://git.kernel.org/stable/c/97bd6c56bdcb41079e488e31df56809e3b2ce628","https://git.kernel.org/stable/c/ccddf8cd411c1800863ed357064e56ceffd356bb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49412 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bfq: Avoid merging queues with different parents It can happen that the parent of a bfqq changes between the moment we decide two queues are worth to merge (and set bic->stable_merge_bfqq) and the moment bfq_setup_merge() is called. This can happen e.g. because the process submitted IO for a different cgroup and thus bfqq got reparented. It can even happen that the bfqq we are merging with has parent cgroup that is already offline and going to be destroyed in which case the merge can lead to use-after-free issues such as: BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50 Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544 CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x46/0x5a print_address_description.constprop.0+0x1f/0x140 ? __bfq_deactivate_entity+0x9cb/0xa50 kasan_report.cold+0x7f/0x11b ? __bfq_deactivate_entity+0x9cb/0xa50 __bfq_deactivate_entity+0x9cb/0xa50 ? update_curr+0x32f/0x5d0 bfq_deactivate_entity+0xa0/0x1d0 bfq_del_bfqq_busy+0x28a/0x420 ? resched_curr+0x116/0x1d0 ? bfq_requeue_bfqq+0x70/0x70 ? check_preempt_wakeup+0x52b/0xbc0 __bfq_bfqq_expire+0x1a2/0x270 bfq_bfqq_expire+0xd16/0x2160 ? try_to_wake_up+0x4ee/0x1260 ? bfq_end_wr_async_queues+0xe0/0xe0 ? _raw_write_unlock_bh+0x60/0x60 ? _raw_spin_lock_irq+0x81/0xe0 bfq_idle_slice_timer+0x109/0x280 ? bfq_dispatch_request+0x4870/0x4870 __hrtimer_run_queues+0x37d/0x700 ? enqueue_hrtimer+0x1b0/0x1b0 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_update_offsets_now+0x6f/0x280 hrtimer_interrupt+0x2c8/0x740 Fix the problem by checking that the parent of the two bfqqs we are merging in bfq_setup_merge() is the same. | ["https://git.kernel.org/stable/c/5ee21edaed09e6b25f2c007b3f326752bc89bacf","https://git.kernel.org/stable/c/7d172b9dc913e161d8ff88770eea01701ff553de","https://git.kernel.org/stable/c/8abc8763b11c35e03cc91d59fd0cd28d39f88ca9","https://git.kernel.org/stable/c/97be7d13fbd4001eeab49b1be6399f23a8c66160","https://git.kernel.org/stable/c/a16c65cca7d2c7ff965fdd3adc8df2156529caf1","https://git.kernel.org/stable/c/c1cee4ab36acef271be9101590756ed0c0c374d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49413 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bfq: Update cgroup information before merging bio When the process is migrated to a different cgroup (or in case of writeback just starts submitting bios associated with a different cgroup) bfq_merge_bio() can operate with stale cgroup information in bic. Thus the bio can be merged to a request from a different cgroup or it can result in merging of bfqqs for different cgroups or bfqqs of already dead cgroups and causing possible use-after-free issues. Fix the problem by updating cgroup information in bfq_merge_bio(). | ["https://git.kernel.org/stable/c/2a1077f17169a6059992a0bbdb330e0abad1e6d9","https://git.kernel.org/stable/c/b06691af08b41dfd81052a3362514d9827b44bb1","https://git.kernel.org/stable/c/d9165200c5627a2cf4408eefabdf0058bdf95e1a","https://git.kernel.org/stable/c/da9f3025d595956410ceaab2bea01980d7775948","https://git.kernel.org/stable/c/e8821f45612f2e6d9adb9c6ba0fb4184f57692aa","https://git.kernel.org/stable/c/ea591cd4eb270393810e7be01feb8fde6a34fbbe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49508 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: elan: Fix potential double free in elan_input_configured 'input' is a managed resource allocated with devm_input_allocate_device(), so there is no need to call input_free_device() explicitly or there will be a double free. According to the doc of devm_input_allocate_device(): * Managed input devices do not need to be explicitly unregistered or * freed as it will be done automatically when owner device unbinds from * its driver (or binding fails). | ["https://git.kernel.org/stable/c/1af20714fedad238362571620be0bd690ded05b6","https://git.kernel.org/stable/c/24f9dfdaece9bd75bb8dbfdba83eddeefdf7dc47","https://git.kernel.org/stable/c/5291451851feeb66fd4bf0826710f482f3b1ab38","https://git.kernel.org/stable/c/6d0726725c7c560495f5ff364862a2cefea542e3","https://git.kernel.org/stable/c/8bb1716507ebf12d50bbf181764481de3b6bc7fd","https://git.kernel.org/stable/c/c92ec22a991778a096342cf1a917ae36c5c86a90","https://git.kernel.org/stable/c/f1d4f19a796551edc6679a681ea1756b8c578c08"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49647 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cgroup: Use separate src/dst nodes when preloading css_sets for migration Each cset (css_set) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mg_preload_node on either the mgctx->preloaded_src_csets or mgctx->preloaded_dst_csets list. Using the same cset->mg_preload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time. Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1: #1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUN_A_COMMAND_WHICH_CREATES_MULTIPLE_THREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one. After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens: 1. cgroup_migrate_add_src() is called on B for the leader. 2. cgroup_migrate_add_src() is called on A for the other threads. 3. cgroup_migrate_prepare_dst() is called. It scans the src list. 4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mg_preload_node is already busy. 5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by list_del_init()'ing its ->mg_preload_node and putting references accordingly. 6. The rest of migration takes place with B on the src list but nothing on the dst list. This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free. This is caused by overloading cset->mg_preload_node for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too. This patch fixes the issue by separating out cset->mg_preload_node into ->mg_src_preload_node and ->mg_dst_preload_node, so that the src and dst preloadings don't interfere with each other. | ["https://git.kernel.org/stable/c/05f7658210d1d331e8dd4cb6e7bbbe3df5f5ac27","https://git.kernel.org/stable/c/07fd5b6cdf3cc30bfde8fe0f644771688be04447","https://git.kernel.org/stable/c/0e41774b564befa6d271e8d5086bf870d617a4e6","https://git.kernel.org/stable/c/54aee4e5ce8c21555286a6333e46c1713880cf93","https://git.kernel.org/stable/c/7657e3958535d101a24ab4400f9b8062b9107cc4","https://git.kernel.org/stable/c/ad44e05f3e016bdcb1ad25af35ade5b5f41ccd68","https://git.kernel.org/stable/c/cec2bbdcc14fbaa6b95ee15a7c423b05d97038be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26961 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org). | ["https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531","https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d","https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1","https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88","https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821","https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f","https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40","https://git.kernel.org/stable/c/068ab2759bc0b4daf0b964de61b2731449c86531","https://git.kernel.org/stable/c/20d3e1c8a1847497269f04d874b2a5818ec29e2d","https://git.kernel.org/stable/c/49c8951680d7b76fceaee89dcfbab1363fb24fd1","https://git.kernel.org/stable/c/640297c3e897bd7e1481466a6a5cb9560f1edb88","https://git.kernel.org/stable/c/d3d858650933d44ac12c1f31337e7110c2071821","https://git.kernel.org/stable/c/dcd51ab42b7a0431575689c5f74b8b6efd45fc2f","https://git.kernel.org/stable/c/e8a1e58345cf40b7b272e08ac7b32328b2543e40","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35869 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: guarantee refcounted children from parent session Avoid potential use-after-free bugs when walking DFS referrals, mounting and performing DFS failover by ensuring that all children from parent @tcon->ses are also refcounted. They're all needed across the entire DFS mount. Get rid of @tcon->dfs_ses_list while we're at it, too. | ["https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a","https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc","https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79","https://git.kernel.org/stable/c/062a7f0ff46eb57aff526897bd2bebfdb1d3046a","https://git.kernel.org/stable/c/645f332c6b63499cc76197f9b6bffcc659ba64cc","https://git.kernel.org/stable/c/e1db9ae87b7148c021daee1fcc4bc71b2ac58a79"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6240 | Medium | N/A | A Marvin vulnerability side-channel leakage was found in the RSA decryption operation in the Linux Kernel. This issue may allow a network attacker to decrypt ciphertexts or forge signatures, limiting the services that use that private key. | ["https://access.redhat.com/errata/RHSA-2024:1881","https://access.redhat.com/errata/RHSA-2024:1882","https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3414","https://access.redhat.com/errata/RHSA-2024:3421","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2023-6240","https://bugzilla.redhat.com/show_bug.cgi?id=2250843","https://people.redhat.com/~hkario/marvin/","https://securitypitfalls.wordpress.com/2023/10/16/experiment-with-side-channel-attacks-yourself/","https://access.redhat.com/errata/RHSA-2024:1881","https://access.redhat.com/errata/RHSA-2024:1882","https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3414","https://access.redhat.com/errata/RHSA-2024:3421","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2023-6240","https://bugzilla.redhat.com/show_bug.cgi?id=2250843","https://people.redhat.com/~hkario/marvin/","https://security.netapp.com/advisory/ntap-20240628-0002/","https://securitypitfalls.wordpress.com/2023/10/16/experiment-with-side-channel-attacks-yourself/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27052 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop(). | ["https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361","https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e","https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e","https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a","https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707","https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59","https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4","https://git.kernel.org/stable/c/1213acb478a7181cd73eeaf00db430f1e45b1361","https://git.kernel.org/stable/c/156012667b85ca7305cb363790d3ae8519a6f41e","https://git.kernel.org/stable/c/3518cea837de4d106efa84ddac18a07b6de1384e","https://git.kernel.org/stable/c/58fe3bbddfec10c6b216096d8c0e517cd8463e3a","https://git.kernel.org/stable/c/7059cdb69f8e1a2707dd1e2f363348b507ed7707","https://git.kernel.org/stable/c/ac512507ac89c01ed6cd4ca53032f52cdb23ea59","https://git.kernel.org/stable/c/dddedfa3b29a63c2ca4336663806a6128b8545b4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42721 | Medium | fixed |
|
A list management bug in BSS handling in the mac80211 stack in the Linux kernel 5.1 through 5.19.x before 5.19.16 could be used by local attackers (able to inject WLAN frames) to corrupt a linked list and, in turn, potentially execute code. | ["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204060","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204060","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bcca852027e5878aec911a347407ecc88d6fff7f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52852 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to avoid use-after-free on dic Call trace: __memcpy+0x128/0x250 f2fs_read_multi_pages+0x940/0xf7c f2fs_mpage_readpages+0x5a8/0x624 f2fs_readahead+0x5c/0x110 page_cache_ra_unbounded+0x1b8/0x590 do_sync_mmap_readahead+0x1dc/0x2e4 filemap_fault+0x254/0xa8c f2fs_filemap_fault+0x2c/0x104 __do_fault+0x7c/0x238 do_handle_mm_fault+0x11bc/0x2d14 do_mem_abort+0x3a8/0x1004 el0_da+0x3c/0xa0 el0t_64_sync_handler+0xc4/0xec el0t_64_sync+0x1b4/0x1b8 In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if we hit cached page in compress_inode's cache, dic may be released, it needs break the loop rather than continuing it, in order to avoid accessing invalid dic pointer. | ["https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5","https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401","https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c","https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2","https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086","https://git.kernel.org/stable/c/8c4504cc0c64862740a6acb301e0cfa59580dbc5","https://git.kernel.org/stable/c/932ddb5c29e884cc6fac20417ece72ba4a35c401","https://git.kernel.org/stable/c/9375ea7f269093d7c884857ae1f47633a91f429c","https://git.kernel.org/stable/c/9d065aa52b6ee1b06f9c4eca881c9b4425a12ba2","https://git.kernel.org/stable/c/b0327c84e91a0f4f0abced8cb83ec86a7083f086"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2019-25162 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag] | ["https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d","https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829","https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7","https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9","https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87","https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf","https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a","https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4","https://git.kernel.org/stable/c/12b0606000d0828630c033bf0c74c748464fe87d","https://git.kernel.org/stable/c/23a191b132cd87f746c62f3dc27da33683d85829","https://git.kernel.org/stable/c/35927d7509ab9bf41896b7e44f639504eae08af7","https://git.kernel.org/stable/c/81cb31756888bb062e92d2dca21cd629d77a46a9","https://git.kernel.org/stable/c/871a1e94929a27bf6e2cd99523865c840bbc2d87","https://git.kernel.org/stable/c/e4c72c06c367758a14f227c847f9d623f1994ecf","https://git.kernel.org/stable/c/e6412ba3b6508bdf9c074d310bf4144afa6aec1a","https://git.kernel.org/stable/c/e8e1a046cf87c8b1363e5de835114f2779e2aaf4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2017-1000377 | Medium | N/A | An issue was discovered in the size of the default stack guard page on PAX Linux (originally from GRSecurity but shipped by other Linux vendors), specifically the default stack guard page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed), this affects PAX Linux Kernel versions as of June 19, 2017 (specific version information is not available at this time). | ["http://www.securityfocus.com/bid/99129","https://access.redhat.com/security/cve/CVE-2017-1000377","https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt","http://www.securityfocus.com/bid/99129","https://access.redhat.com/security/cve/CVE-2017-1000377","https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50265 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] <TASK> [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy. | ["https://git.kernel.org/stable/c/0b63c0e01fba40e3992bc627272ec7b618ccaef7","https://git.kernel.org/stable/c/168a9b8303fcb0317db4c06b23ce1c0ce2af4e10","https://git.kernel.org/stable/c/2b5369528ee63c88371816178a05b5e664c87386","https://git.kernel.org/stable/c/38cbf13b2e7a31362babe411f7c2c3c52cd2734b","https://git.kernel.org/stable/c/6a7e6dcf90fe7721d0863067b6ca9a9442134692","https://git.kernel.org/stable/c/86dd0e8d42828923c68ad506933336bcd6f2317d","https://git.kernel.org/stable/c/dcc8fe8c83145041cb6c80cac21f6173a3ff0204","https://git.kernel.org/stable/c/dd73c942eed76a014c7a5597e6926435274d2c4c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48983 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: Fix a null-ptr-deref in io_tctx_exit_cb() Syzkaller reports a NULL deref bug as follows: BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3 Read of size 4 at addr 0000000000000138 by task file1/1955 CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ? io_tctx_exit_cb+0x53/0xd3 kasan_report+0xbb/0x1f0 ? io_tctx_exit_cb+0x53/0xd3 kasan_check_range+0x140/0x190 io_tctx_exit_cb+0x53/0xd3 task_work_run+0x164/0x250 ? task_work_cancel+0x30/0x30 get_signal+0x1c3/0x2440 ? lock_downgrade+0x6e0/0x6e0 ? lock_downgrade+0x6e0/0x6e0 ? exit_signals+0x8b0/0x8b0 ? do_raw_read_unlock+0x3b/0x70 ? do_raw_spin_unlock+0x50/0x230 arch_do_signal_or_restart+0x82/0x2470 ? kmem_cache_free+0x260/0x4b0 ? putname+0xfe/0x140 ? get_sigframe_size+0x10/0x10 ? do_execveat_common.isra.0+0x226/0x710 ? lockdep_hardirqs_on+0x79/0x100 ? putname+0xfe/0x140 ? do_execveat_common.isra.0+0x238/0x710 exit_to_user_mode_prepare+0x15f/0x250 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x42/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0023:0x0 Code: Unable to access opcode bytes at 0xffffffffffffffd6. RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: panic_on_warn set ... This happens because the adding of task_work from io_ring_exit_work() isn't synchronized with canceling all work items from eg exec. The execution of the two are ordered in that they are both run by the task itself, but if io_tctx_exit_cb() is queued while we're canceling all work items off exec AND gets executed when the task exits to userspace rather than in the main loop in io_uring_cancel_generic(), then we can find current->io_uring == NULL and hit the above crash. It's safe to add this NULL check here, because the execution of the two paths are done by the task itself. [axboe: add code comment and also put an explanation in the commit msg] | ["https://git.kernel.org/stable/c/998b30c3948e4d0b1097e639918c5cff332acac5","https://git.kernel.org/stable/c/d91edca1943453aaaba4f380f6f364346222e5cf","https://git.kernel.org/stable/c/f895511de9d27fff71dad2c234ad53b4afd2b06c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52819 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga For pptable structs that use flexible array sizes, use flexible arrays. | ["https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356","https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6","https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216","https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92","https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1","https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e","https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18","https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4","https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679","https://git.kernel.org/stable/c/0f0e59075b5c22f1e871fbd508d6e4f495048356","https://git.kernel.org/stable/c/60a00dfc7c5deafd1dd393beaf53224f7256dad6","https://git.kernel.org/stable/c/7c68283f3166221af3df5791f0e13d3137a72216","https://git.kernel.org/stable/c/8c1dbddbfcb051e82cea0c197c620f9dcdc38e92","https://git.kernel.org/stable/c/a237675aa1e62bbfaa341c535331c8656a508fa1","https://git.kernel.org/stable/c/a63fd579e7b1c3a9ebd6e6c494d49b1b6cf5515e","https://git.kernel.org/stable/c/b3b8b7c040cf069da7afe11c5bd73b870b8f3d18","https://git.kernel.org/stable/c/d0725232da777840703f5f1e22f2e3081d712aa4","https://git.kernel.org/stable/c/d50a56749e5afdc63491b88f5153c1aae00d4679"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-10882 | Medium | N/A | A flaw was found in the Linux kernel's ext4 filesystem. A local user can cause an out-of-bound write in in fs/jbd2/transaction.c code, a denial of service, and a system crash by unmounting a crafted ext4 filesystem image. | ["http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2018:2948","https://bugzilla.kernel.org/show_bug.cgi?id=200069","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10882","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c37e9e013469521d9adb932d17a1795c139b36db","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2018:2948","https://bugzilla.kernel.org/show_bug.cgi?id=200069","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10882","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c37e9e013469521d9adb932d17a1795c139b36db","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52837 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nbd: fix uaf in nbd_open Commit 4af5f2e03013 ("nbd: use blk_mq_alloc_disk and blk_cleanup_disk") cleans up disk by blk_cleanup_disk() and it won't set disk->private_data as NULL as before. UAF may be triggered in nbd_open() if someone tries to open nbd device right after nbd_put() since nbd has been free in nbd_dev_remove(). Fix this by implementing ->free_disk and free private data in it. | ["https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b","https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3","https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe","https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db","https://git.kernel.org/stable/c/327462725b0f759f093788dfbcb2f1fd132f956b","https://git.kernel.org/stable/c/4e9b3ec84dc97909876641dad14e0a2300d6c2a3","https://git.kernel.org/stable/c/56bd7901b5e9dbc9112036ea615ebcba1565fafe","https://git.kernel.org/stable/c/879947f4180bc6e83af64eb0515e0cf57fce15db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35861 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_signal_cifsd_for_reconnect() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1","https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4","https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f","https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d","https://git.kernel.org/stable/c/2cfff21732132e363b4cc275d63ea98f1af726c1","https://git.kernel.org/stable/c/7e8360ac8774e19b0b25f44fff84a105bb2417e4","https://git.kernel.org/stable/c/e0e50401cc3921c9eaf1b0e667db174519ea939f","https://git.kernel.org/stable/c/f9a96a7ad1e8d25dc6662bc7552e0752de74a20d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35862 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_network_name_deleted() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d","https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01","https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645","https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c","https://git.kernel.org/stable/c/63981561ffd2d4987807df4126f96a11e18b0c1d","https://git.kernel.org/stable/c/aa582b33f94453fdeaff1e7d0aa252c505975e01","https://git.kernel.org/stable/c/d919b6ea15ffa56fbafef4a1d92f47aeda9af645","https://git.kernel.org/stable/c/f9414004798d9742c1af23a1d839fe6a9503751c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35863 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2","https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825","https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac","https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29","https://git.kernel.org/stable/c/0a15ba88a32fa7a516aff7ffd27befed5334dff2","https://git.kernel.org/stable/c/16d58c6a7db5050b9638669084b63fc05f951825","https://git.kernel.org/stable/c/494c91e1e9413b407d12166a61b84200d4d54fac","https://git.kernel.org/stable/c/69ccf040acddf33a3a85ec0f6b45ef84b0f7ec29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35864 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_lease_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1","https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb","https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5","https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4","https://git.kernel.org/stable/c/705c76fbf726c7a2f6ff9143d4013b18daaaebf1","https://git.kernel.org/stable/c/a8344e2b69bde63f713b0aa796d70dbeadffddfb","https://git.kernel.org/stable/c/c868cabdf6fdd61bea54532271f4708254e57fc5","https://git.kernel.org/stable/c/f92739fdd4522c4291277136399353d7c341fae4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35868 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_write() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b","https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72","https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7","https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a","https://git.kernel.org/stable/c/5b5475ce69f02ecc1b13ea23106e5b89c690429b","https://git.kernel.org/stable/c/8fefd166fcb368c5fcf48238e3f7c8af829e0a72","https://git.kernel.org/stable/c/cf03020c56d3ed28c4942280957a007b5e9544f7","https://git.kernel.org/stable/c/d3da25c5ac84430f89875ca7485a3828150a7e0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36012 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: msft: fix slab-use-after-free in msft_do_close() Tying the msft->data lifetime to hdev by freeing it in hci_release_dev() to fix the following case: [use] msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed. [free] msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed. ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30 kernel/locking/mutex.c:752 Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309 | ["https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac","https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56","https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940","https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76","https://git.kernel.org/stable/c/10f9f426ac6e752c8d87bf4346930ba347aaabac","https://git.kernel.org/stable/c/4f1de02de07748da80a8178879bc7a1df37fdf56","https://git.kernel.org/stable/c/a85a60e62355e3bf4802dead7938966824b23940","https://git.kernel.org/stable/c/e3880b531b68f98d3941d83f2f6dd11cf4fd6b76"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40956 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list Use list_for_each_entry_safe() to allow iterating through the list and deleting the entry in the iteration process. The descriptor is freed via idxd_desc_complete() and there's a slight chance may cause issue for the list iterator when the descriptor is reused by another thread without it being deleted from the list. | ["https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33","https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5","https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd","https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7","https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8","https://git.kernel.org/stable/c/1b08bf5a17c66ab7dbb628df5344da53c8e7ab33","https://git.kernel.org/stable/c/83163667d881100a485b6c2daa30301b7f68d9b5","https://git.kernel.org/stable/c/a14968921486793f2a956086895c3793761309dd","https://git.kernel.org/stable/c/e3215deca4520773cd2b155bed164c12365149a7","https://git.kernel.org/stable/c/faa35db78b058a2ab6e074ee283f69fa398c36a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49291 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent hw_params and hw_free calls Currently we have neither proper check nor protection against the concurrent calls of PCM hw_params and hw_free ioctls, which may result in a UAF. Since the existing PCM stream lock can't be used for protecting the whole ioctl operations, we need a new mutex to protect those racy calls. This patch introduced a new mutex, runtime->buffer_mutex, and applies it to both hw_params and hw_free ioctl code paths. Along with it, the both functions are slightly modified (the mmap_count check is moved into the state-check block) for code simplicity. | ["https://git.kernel.org/stable/c/0090c13cbbdffd7da079ac56f80373a9a1be0bf8","https://git.kernel.org/stable/c/0f6947f5f5208f6ebd4d76a82a4757e2839a23f8","https://git.kernel.org/stable/c/1bbf82d9f961414d6c76a08f7f843ea068e0ab7b","https://git.kernel.org/stable/c/33061d0fba51d2bf70a2ef9645f703c33fe8e438","https://git.kernel.org/stable/c/92ee3c60ec9fe64404dc035e7c41277d74aa26cb","https://git.kernel.org/stable/c/9cb6c40a6ebe4a0cfc9d6a181958211682cffea9","https://git.kernel.org/stable/c/a42aa926843acca96c0dfbde2e835b8137f2f092","https://git.kernel.org/stable/c/fbeb492694ce0441053de57699e1e2b7bc148a69"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49388 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_create_volume: Fix use-after-free when volume creation failed There is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'s error handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tbl out_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl' out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAF Fix it by removing redundant 'eba_tbl' releasing. Fetch a reproducer in [Link]. | ["https://git.kernel.org/stable/c/1174ab8ba36a48025b68b5ff1085000b1e510217","https://git.kernel.org/stable/c/25ff1e3a1351c0d936dd1ac2f9e58231ea1510c9","https://git.kernel.org/stable/c/5ff2514e4fb55dcf3d88294686040ca73ea0c1a2","https://git.kernel.org/stable/c/6d8d3f68cbecfd31925796f0fb668eb21ab06734","https://git.kernel.org/stable/c/8302620aeb940f386817321d272b12411ae7d39f","https://git.kernel.org/stable/c/8c03a1c21d72210f81cb369cc528e3fde4b45411","https://git.kernel.org/stable/c/abb67043060f2bf4c03d7c3debb9ae980e2b6db3","https://git.kernel.org/stable/c/e27ecf325e51abd06aaefba57a6322a46fa4178b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49700 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr() (enables preemption) - [PREEMPT B->A] - task A: finish do_slab_free(): - this_cpu_cmpxchg_double() succeeds() - [CORRUPT STATE: c->slab==NULL, c->freelist!=NULL] From there, the object on c->freelist will get lost if task B is allowed to continue from here: It will proceed to the retry_load_slab label, set c->slab, then jump to load_freelist, which clobbers c->freelist. But if we instead continue as follows, we get worse corruption: - task A: run __slab_free() on object from other struct slab: - CPU_PARTIAL_FREE case (slab was on no list, is now on pcpu partial) - task A: run slab_alloc_node() with NUMA node constraint: - fastpath fails (c->slab is NULL) - call __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - c->slab is NULL: goto new_slab - slub_percpu_partial() is non-NULL - set c->slab to slub_percpu_partial(c) - [CORRUPT STATE: c->slab points to slab-1, c->freelist has objects from slab-2] - goto redo - node_match() fails - goto deactivate_slab - existing c->freelist is passed into deactivate_slab() - inuse count of slab-1 is decremented to account for object from slab-2 At this point, the inuse count of slab-1 is 1 lower than it should be. This means that if we free all allocated objects in slab-1 except for one, SLUB will think that slab-1 is completely unused, and may free its page, leading to use-after-free. | ["https://git.kernel.org/stable/c/0515cc9b6b24877f59b222ade704bfaa42caa2a6","https://git.kernel.org/stable/c/197e257da473c725dfe47759c3ee02f2398d8ea5","https://git.kernel.org/stable/c/308c6d0e1f200fd26c71270c6e6bfcf0fc6ff082","https://git.kernel.org/stable/c/6c32496964da0dc230cea763a0e934b2e02dabd5","https://git.kernel.org/stable/c/d6a597450e686d4c6388bd3cdcb17224b4dae7f0","https://git.kernel.org/stable/c/e2b2f0e2e34d71ae6c2a1114fd3c525930e84bc7","https://git.kernel.org/stable/c/e7e3e90d671078455a3a08189f89d85b3da2de9e","https://git.kernel.org/stable/c/eeaa345e128515135ccb864c04482180c08e3259"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46674 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: st: fix probed platform device ref count on probe error path The probe function never performs any paltform device allocation, thus error path "undo_platform_dev_alloc" is entirely bogus. It drops the reference count from the platform device being probed. If error path is triggered, this will lead to unbalanced device reference counts and premature release of device resources, thus possible use-after-free when releasing remaining devm-managed resources. | ["https://git.kernel.org/stable/c/060f41243ad7f6f5249fa7290dda0c01f723d12d","https://git.kernel.org/stable/c/1de989668708ce5875efc9d669d227212aeb9a90","https://git.kernel.org/stable/c/4c6735299540f3c82a5033d35be76a5c42e0fb18","https://git.kernel.org/stable/c/6aee4c5635d81f4809c3b9f0c198a65adfbb2ada","https://git.kernel.org/stable/c/b0979a885b9d4df2a25b88e9d444ccaa5f9f495c","https://git.kernel.org/stable/c/ddfcfeba891064b88bb844208b43bef2ef970f0c","https://git.kernel.org/stable/c/e1e5e8ea2731150d5ba7c707f9e02fafebcfeb49","https://git.kernel.org/stable/c/f3498650df0805c75b4e1c94d07423c46cbf4ce1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52812 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd: check num of link levels when update pcie param In SR-IOV environment, the value of pcie_table->num_of_link_levels will be 0, and num_of_levels - 1 will cause array index out of bounds | ["https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a","https://git.kernel.org/stable/c/2f2d48b6247ae3001f83c98730b3cce475cb2927","https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec","https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670","https://git.kernel.org/stable/c/09f617219fe9ccd8d7b65dc3e879b5889f663b5a","https://git.kernel.org/stable/c/406e8845356d18bdf3d3a23b347faf67706472ec","https://git.kernel.org/stable/c/5b4574b663d0a1a0a62d5232429b7db9ae6d0670"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26983 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bootconfig: use memblock_free_late to free xbc memory to buddy On the time to free xbc memory in xbc_exit(), memblock may has handed over memory to buddy allocator. So it doesn't make sense to free memory back to memblock. memblock_free() called by xbc_exit() even causes UAF bugs on architectures with CONFIG_ARCH_KEEP_MEMBLOCK disabled like x86. Following KASAN logs shows this case. This patch fixes the xbc memory free problem by calling memblock_free() in early xbc init error rewind path and calling memblock_free_late() in xbc exit path to free memory to buddy allocator. [ 9.410890] ================================================================== [ 9.418962] BUG: KASAN: use-after-free in memblock_isolate_range+0x12d/0x260 [ 9.426850] Read of size 8 at addr ffff88845dd30000 by task swapper/0/1 [ 9.435901] CPU: 9 PID: 1 Comm: swapper/0 Tainted: G U 6.9.0-rc3-00208-g586b5dfb51b9 #5 [ 9.446403] Hardware name: Intel Corporation RPLP LP5 (CPU:RaptorLake)/RPLP LP5 (ID:13), BIOS IRPPN02.01.01.00.00.19.015.D-00000000 Dec 28 2023 [ 9.460789] Call Trace: [ 9.463518] <TASK> [ 9.465859] dump_stack_lvl+0x53/0x70 [ 9.469949] print_report+0xce/0x610 [ 9.473944] ? __virt_addr_valid+0xf5/0x1b0 [ 9.478619] ? memblock_isolate_range+0x12d/0x260 [ 9.483877] kasan_report+0xc6/0x100 [ 9.487870] ? memblock_isolate_range+0x12d/0x260 [ 9.493125] memblock_isolate_range+0x12d/0x260 [ 9.498187] memblock_phys_free+0xb4/0x160 [ 9.502762] ? __pfx_memblock_phys_free+0x10/0x10 [ 9.508021] ? mutex_unlock+0x7e/0xd0 [ 9.512111] ? __pfx_mutex_unlock+0x10/0x10 [ 9.516786] ? kernel_init_freeable+0x2d4/0x430 [ 9.521850] ? __pfx_kernel_init+0x10/0x10 [ 9.526426] xbc_exit+0x17/0x70 [ 9.529935] kernel_init+0x38/0x1e0 [ 9.533829] ? _raw_spin_unlock_irq+0xd/0x30 [ 9.538601] ret_from_fork+0x2c/0x50 [ 9.542596] ? __pfx_kernel_init+0x10/0x10 [ 9.547170] ret_from_fork_asm+0x1a/0x30 [ 9.551552] </TASK> [ 9.555649] The buggy address belongs to the physical page: [ 9.561875] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x45dd30 [ 9.570821] flags: 0x200000000000000(node=0|zone=2) [ 9.576271] page_type: 0xffffffff() [ 9.580167] raw: 0200000000000000 ffffea0011774c48 ffffea0012ba1848 0000000000000000 [ 9.588823] raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 [ 9.597476] page dumped because: kasan: bad access detected [ 9.605362] Memory state around the buggy address: [ 9.610714] ffff88845dd2ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.618786] ffff88845dd2ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 9.626857] >ffff88845dd30000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.634930] ^ [ 9.638534] ffff88845dd30080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.646605] ffff88845dd30100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 9.654675] ================================================================== | ["https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918","https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35","https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0","https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7","https://git.kernel.org/stable/c/1e7feb31a18c197d63a5e606025ed63c762f8918","https://git.kernel.org/stable/c/5a7dfb8fcd3f29fc93161100179b27f24f3d5f35","https://git.kernel.org/stable/c/89f9a1e876b5a7ad884918c03a46831af202c8a0","https://git.kernel.org/stable/c/e46d3be714ad9652480c6db129ab8125e2d20ab7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52810 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/jfs: Add check for negative db_l2nbperpage l2nbperpage is log2(number of blks per page), and the minimum legal value should be 0, not negative. In the case of l2nbperpage being negative, an error will occur when subsequently used as shift exponent. Syzbot reported this bug: UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12 shift exponent -16777216 is negative | ["https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6","https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b","https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45","https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907","https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa","https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f","https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc","https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1","https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01","https://git.kernel.org/stable/c/0cb567e727339a192f9fd0db00781d73a91d15a6","https://git.kernel.org/stable/c/1a7c53fdea1d189087544d9a606d249e93c4934b","https://git.kernel.org/stable/c/491085258185ffc4fb91555b0dba895fe7656a45","https://git.kernel.org/stable/c/524b4f203afcf87accfe387e846f33f916f0c907","https://git.kernel.org/stable/c/525b861a008143048535011f3816d407940f4bfa","https://git.kernel.org/stable/c/5f148b16972e5f4592629b244d5109b15135f53f","https://git.kernel.org/stable/c/8f2964df6bfce9d92d81ca552010b8677af8d9dc","https://git.kernel.org/stable/c/a81a56b4cbe3142cc99f6b98e8f9b3a631c768e1","https://git.kernel.org/stable/c/cc61fcf7d1c99f148fe8ddfb5c6ed0bb75861f01"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42309 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee","https://git.kernel.org/stable/c/2df7aac81070987b0f052985856aa325a38debf6","https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692","https://git.kernel.org/stable/c/475a5b3b7c8edf6e583a9eb59cf28ea770602e14","https://git.kernel.org/stable/c/6735d02ead7dd3adf74eb8b70aebd09e0ce78ec9","https://git.kernel.org/stable/c/7e52c62ff029f95005915c0a11863b5fb5185c8c","https://git.kernel.org/stable/c/d6ad202f73f8edba0cbc0065aa57a79ffe8fdcdc","https://git.kernel.org/stable/c/f70ffeca546452d1acd3a70ada56ecb2f3e7f811"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42310 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modes In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/08f45102c81ad8bc9f85f7a25e9f64e128edb87d","https://git.kernel.org/stable/c/2d209b2f862f6b8bff549ede541590a8d119da23","https://git.kernel.org/stable/c/977ee4fe895e1729cd36cc26916bbb10084713d6","https://git.kernel.org/stable/c/a658ae2173ab74667c009e2550455e6de5b33ddc","https://git.kernel.org/stable/c/b6ac46a00188cde50ffba233e6efb366354a1de5","https://git.kernel.org/stable/c/cb520c3f366c77e8d69e4e2e2781a8ce48d98e79","https://git.kernel.org/stable/c/e74eb5e8089427c8c49e0dd5067e5f39ce3a4d56","https://git.kernel.org/stable/c/f392c36cebf4c1d6997a4cc2c0f205254acef42a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43834 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xdp: fix invalid wait context of page_pool_destroy() If the driver uses a page pool, it creates a page pool with page_pool_create(). The reference count of page pool is 1 as default. A page pool will be destroyed only when a reference count reaches 0. page_pool_destroy() is used to destroy page pool, it decreases a reference count. When a page pool is destroyed, ->disconnect() is called, which is mem_allocator_disconnect(). This function internally acquires mutex_lock(). If the driver uses XDP, it registers a memory model with xdp_rxq_info_reg_mem_model(). The xdp_rxq_info_reg_mem_model() internally increases a page pool reference count if a memory model is a page pool. Now the reference count is 2. To destroy a page pool, the driver should call both page_pool_destroy() and xdp_unreg_mem_model(). The xdp_unreg_mem_model() internally calls page_pool_destroy(). Only page_pool_destroy() decreases a reference count. If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we will face an invalid wait context warning. Because xdp_unreg_mem_model() calls page_pool_destroy() with rcu_read_lock(). The page_pool_destroy() internally acquires mutex_lock(). Splat looks like: ============================= [ BUG: Invalid wait context ] 6.10.0-rc6+ #4 Tainted: G W ----------------------------- ethtool/1806 is trying to lock: ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150 other info that might help us debug this: context-{5:5} 3 locks held by ethtool/1806: stack backtrace: CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021 Call Trace: <TASK> dump_stack_lvl+0x7e/0xc0 __lock_acquire+0x1681/0x4de0 ? _printk+0x64/0xe0 ? __pfx_mark_lock.part.0+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x1b3/0x580 ? mem_allocator_disconnect+0x73/0x150 ? __wake_up_klogd.part.0+0x16/0xc0 ? __pfx_lock_acquire+0x10/0x10 ? dump_stack_lvl+0x91/0xc0 __mutex_lock+0x15c/0x1690 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_prb_read_valid+0x10/0x10 ? mem_allocator_disconnect+0x73/0x150 ? __pfx_llist_add_batch+0x10/0x10 ? console_unlock+0x193/0x1b0 ? lockdep_hardirqs_on+0xbe/0x140 ? __pfx___mutex_lock+0x10/0x10 ? tick_nohz_tick_stopped+0x16/0x90 ? __irq_work_queue_local+0x1e5/0x330 ? irq_work_queue+0x39/0x50 ? __wake_up_klogd.part.0+0x79/0xc0 ? mem_allocator_disconnect+0x73/0x150 mem_allocator_disconnect+0x73/0x150 ? __pfx_mem_allocator_disconnect+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? rcu_is_watching+0x11/0xb0 page_pool_release+0x36e/0x6d0 page_pool_destroy+0xd7/0x440 xdp_unreg_mem_model+0x1a7/0x2a0 ? __pfx_xdp_unreg_mem_model+0x10/0x10 ? kfree+0x125/0x370 ? bnxt_free_ring.isra.0+0x2eb/0x500 ? bnxt_free_mem+0x5ac/0x2500 xdp_rxq_info_unreg+0x4a/0xd0 bnxt_free_mem+0x1356/0x2500 bnxt_close_nic+0xf0/0x3b0 ? __pfx_bnxt_close_nic+0x10/0x10 ? ethnl_parse_bit+0x2c6/0x6d0 ? __pfx___nla_validate_parse+0x10/0x10 ? __pfx_ethnl_parse_bit+0x10/0x10 bnxt_set_features+0x2a8/0x3e0 __netdev_update_features+0x4dc/0x1370 ? ethnl_parse_bitset+0x4ff/0x750 ? __pfx_ethnl_parse_bitset+0x10/0x10 ? __pfx___netdev_update_features+0x10/0x10 ? mark_held_locks+0xa5/0xf0 ? _raw_spin_unlock_irqrestore+0x42/0x70 ? __pm_runtime_resume+0x7d/0x110 ethnl_set_features+0x32d/0xa20 To fix this problem, it uses rhashtable_lookup_fast() instead of rhashtable_lookup() with rcu_read_lock(). Using xa without rcu_read_lock() here is safe. xa is freed by __xdp_mem_allocator_rcu_free() and this is called by call_rcu() of mem_xa_remove(). The mem_xa_remove() is called by page_pool_destroy() if a reference count reaches 0. The xa is already protected by the reference count mechanism well in the control plane. So removing rcu_read_lock() for page_pool_destroy() is safe. | ["https://git.kernel.org/stable/c/12144069209eec7f2090ce9afa15acdcc2c2a537","https://git.kernel.org/stable/c/3fc1be360b99baeea15cdee3cf94252cd3a72d26","https://git.kernel.org/stable/c/59a931c5b732ca5fc2ca727f5a72aeabaafa85ec","https://git.kernel.org/stable/c/6c390ef198aa69795427a5cb5fd7cb4bc7e6cd7a","https://git.kernel.org/stable/c/be9d08ff102df3ac4f66e826ea935cf3af63a4bd","https://git.kernel.org/stable/c/bf0ce5aa5f2525ed1b921ba36de96e458e77f482"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43860 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: remoteproc: imx_rproc: Skip over memory region when node value is NULL In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. [Fixed title to fit within the prescribed 70-75 charcters] | ["https://git.kernel.org/stable/c/2fa26ca8b786888673689ccc9da6094150939982","https://git.kernel.org/stable/c/4e13b7c23988c0a13fdca92e94296a3bc2ff9f21","https://git.kernel.org/stable/c/6884fd0283e0831be153fb8d82d9eda8a55acaaa","https://git.kernel.org/stable/c/6b50462b473fdccdc0dfad73001147e40ff19a66","https://git.kernel.org/stable/c/6c9ea3547fad252fe9ae5d3ed7e066e2085bf3a2","https://git.kernel.org/stable/c/84beb7738459cac0ff9f8a7c4654b8ff82a702c0","https://git.kernel.org/stable/c/9a17cf8b2ce483fa75258bc2cdcf628f24bcf5f8","https://git.kernel.org/stable/c/c877a5f5268d4ab8224b9c9fbce3d746e4e72bc9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44988 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix out-of-bound access If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array). | ["https://git.kernel.org/stable/c/050e7274ab2150cd212b2372595720e7b83a15bd","https://git.kernel.org/stable/c/18b2e833daf049223ab3c2efdf8cdee08854c484","https://git.kernel.org/stable/c/4a88fca95c8df3746b71e31f44a02d35f06f9864","https://git.kernel.org/stable/c/528876d867a23b5198022baf2e388052ca67c952","https://git.kernel.org/stable/c/a10d0337115a6d223a1563d853d4455f05d0b2e3","https://git.kernel.org/stable/c/d39f5be62f098fe367d672b4dd4bc4b2b80e08e7","https://git.kernel.org/stable/c/f7d8c2fabd39250cf2333fbf8eef67e837f90a5d","https://git.kernel.org/stable/c/f87ce03c652dba199aef15ac18ade3991db5477e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45021 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memcg_write_event_control(): fix a user-triggerable oops we are *not* guaranteed that anything past the terminating NUL is mapped (let alone initialized with anything sane). | ["https://git.kernel.org/stable/c/046667c4d3196938e992fba0dfcde570aa85cd0e","https://git.kernel.org/stable/c/0fbe2a72e853a1052abe9bc2b7df8ddb102da227","https://git.kernel.org/stable/c/1b37ec85ad95b612307627758c6018cd9d92cca8","https://git.kernel.org/stable/c/21b578f1d599edb87462f11113c5b0fc7a04ac61","https://git.kernel.org/stable/c/43768fa80fd192558737e24ed6548f74554611d7","https://git.kernel.org/stable/c/ad149f5585345e383baa65f1539d816cd715fd3b","https://git.kernel.org/stable/c/f1aa7c509aa766080db7ab3aec2e31b1df09e57c","https://git.kernel.org/stable/c/fa5bfdf6cb5846a00e712d630a43e3cf55ccb411"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46677 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gtp: fix a potential NULL pointer dereference When sockfd_lookup() fails, gtp_encap_enable_socket() returns a NULL pointer, but its callers only check for error pointers thus miss the NULL pointer case. Fix it by returning an error pointer with the error code carried from sockfd_lookup(). (I found this bug during code inspection.) | ["https://git.kernel.org/stable/c/28c67f0f84f889fe9f4cbda8354132b20dc9212d","https://git.kernel.org/stable/c/4643b91691e969b1b9ad54bf552d7a990cfa3b87","https://git.kernel.org/stable/c/612edd35f2a3910ab1f61c1f2338889d4ba99fa2","https://git.kernel.org/stable/c/620fe9809752fae91b4190e897b81ed9976dfb39","https://git.kernel.org/stable/c/8bbb9e4e0e66a39282e582d0440724055404b38c","https://git.kernel.org/stable/c/bdd99e5f0ad5fa727b16f2101fe880aa2bff2f8e","https://git.kernel.org/stable/c/defd8b3c37b0f9cb3e0f60f47d3d78d459d57fda","https://git.kernel.org/stable/c/e8b9930b0eb045d19e883c65ff9676fc89320c70"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1194 | High | fixed |
|
An out-of-bounds (OOB) memory read flaw was found in parse_lease_state in the KSMBD implementation of the in-kernel samba server and CIFS in the Linux kernel. When an attacker sends the CREATE command with a malformed payload to KSMBD, due to a missing check of `NameOffset` in the `parse_lease_state()` function, the `create_context` object can access invalid memory. | ["https://access.redhat.com/security/cve/CVE-2023-1194","https://bugzilla.redhat.com/show_bug.cgi?id=2154176","https://security.netapp.com/advisory/ntap-20231221-0006/","https://www.spinics.net/lists/stable-commits/msg303065.html","https://access.redhat.com/security/cve/CVE-2023-1194","https://bugzilla.redhat.com/show_bug.cgi?id=2154176","https://security.netapp.com/advisory/ntap-20231221-0006/","https://www.spinics.net/lists/stable-commits/msg303065.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42224 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Correct check for empty list Since commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIO busses") mv88e6xxx_default_mdio_bus() has checked that the return value of list_first_entry() is non-NULL. This appears to be intended to guard against the list chip->mdios being empty. However, it is not the correct check as the implementation of list_first_entry is not designed to return NULL for empty lists. Instead, use list_first_entry_or_null() which does return NULL if the list is empty. Flagged by Smatch. Compile tested only. | ["https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5","https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618","https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d","https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee","https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b","https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114","https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89","https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4","https://git.kernel.org/stable/c/2a2fe25a103cef73cde356e6d09da10f607e93f5","https://git.kernel.org/stable/c/3bf8d70e1455f87856640c3433b3660a31001618","https://git.kernel.org/stable/c/3f25b5f1635449036692a44b771f39f772190c1d","https://git.kernel.org/stable/c/47d28dde172696031c880c5778633cdca30394ee","https://git.kernel.org/stable/c/4c7f3950a9fd53a62b156c0fe7c3a2c43b0ba19b","https://git.kernel.org/stable/c/8c2c3cca816d074c75a2801d1ca0dea7b0148114","https://git.kernel.org/stable/c/aa03f591ef31ba603a4a99d05d25a0f21ab1cd89","https://git.kernel.org/stable/c/f75625db838ade28f032dacd0f0c8baca42ecde4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48702 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc() The voice allocator sometimes begins allocating from near the end of the array and then wraps around, however snd_emu10k1_pcm_channel_alloc() accesses the newly allocated voices as if it never wrapped around. This results in out of bounds access if the first voice has a high enough index so that first_voice + requested_voice_count > NUM_G (64). The more voices are requested, the more likely it is for this to occur. This was initially discovered using PipeWire, however it can be reproduced by calling aplay multiple times with 16 channels: aplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero UBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40 index 65 is out of range for type 'snd_emu10k1_voice [64]' CPU: 1 PID: 31977 Comm: aplay Tainted: G W IOE 6.0.0-rc2-emu10k1+ #7 Hardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002 07/22/2010 Call Trace: <TASK> dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x3f __ubsan_handle_out_of_bounds.cold+0x44/0x49 snd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1] snd_pcm_hw_params+0x29f/0x600 [snd_pcm] snd_pcm_common_ioctl+0x188/0x1410 [snd_pcm] ? exit_to_user_mode_prepare+0x35/0x170 ? do_syscall_64+0x69/0x90 ? syscall_exit_to_user_mode+0x26/0x50 ? do_syscall_64+0x69/0x90 ? exit_to_user_mode_prepare+0x35/0x170 snd_pcm_ioctl+0x27/0x40 [snd_pcm] __x64_sys_ioctl+0x95/0xd0 do_syscall_64+0x5c/0x90 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c","https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178","https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2","https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1","https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa","https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275","https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7","https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f","https://git.kernel.org/stable/c/39a90720f3abe96625d1224e7a7463410875de4c","https://git.kernel.org/stable/c/4204a01ffce97cae1d59edc5848f02be5b2b9178","https://git.kernel.org/stable/c/45321a7d02b7cf9b3f97e3987fc1e4d649b82da2","https://git.kernel.org/stable/c/45814a53514e10a8014906c882e0d0d38df39cc1","https://git.kernel.org/stable/c/637c5310acb48fffcc5657568db3f3e9bc719bfa","https://git.kernel.org/stable/c/6b0e260ac3cf289e38446552461caa65e6dab275","https://git.kernel.org/stable/c/88aac6684cf8bc885cca15463cb4407e91f28ff7","https://git.kernel.org/stable/c/d29f59051d3a07b81281b2df2b8c9dfe4716067f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52840 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: synaptics-rmi4 - fix use after free in rmi_unregister_function() The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this. | ["https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f","https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2","https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff","https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5","https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f","https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585","https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683","https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1","https://git.kernel.org/stable/c/2f236d8638f5b43e0c72919a6a27fe286c32053f","https://git.kernel.org/stable/c/303766bb92c5c225cf40f9bbbe7e29749406e2f2","https://git.kernel.org/stable/c/50d12253666195a14c6cd2b81c376e2dbeedbdff","https://git.kernel.org/stable/c/6c71e065befb2fae8f1461559b940c04e1071bd5","https://git.kernel.org/stable/c/7082b1fb5321037bc11ba1cf2d7ed23c6b2b521f","https://git.kernel.org/stable/c/c8e639f5743cf4b01f8c65e0df075fe4d782b585","https://git.kernel.org/stable/c/cc56c4d17721dcb10ad4e9c9266e449be1462683","https://git.kernel.org/stable/c/eb988e46da2e4eae89f5337e047ce372fe33d5b1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38545 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix UAF for cq async event The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF. Use the xa_lock() to protect the CQ refcount. | ["https://git.kernel.org/stable/c/330c825e66ef65278e4ebe57fd49c1d6f3f4e34e","https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507","https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911","https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08","https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf","https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42","https://git.kernel.org/stable/c/37a7559dc1358a8d300437e99ed8ecdab0671507","https://git.kernel.org/stable/c/39d26cf46306bdc7ae809ecfdbfeff5aa1098911","https://git.kernel.org/stable/c/63da190eeb5c9d849b71f457b15b308c94cbaf08","https://git.kernel.org/stable/c/763780ef0336a973e933e40e919339381732dcaf","https://git.kernel.org/stable/c/a942ec2745ca864cd8512142100e4027dc306a42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38588 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix possible use-after-free issue in ftrace_location() KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79 The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free! To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem(). | ["https://git.kernel.org/stable/c/1880a324af1c95940a7c954b6b937e86844a33bd","https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b","https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6","https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461","https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831","https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada","https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d","https://git.kernel.org/stable/c/eea46baf145150910ba134f75a67106ba2222c1b","https://git.kernel.org/stable/c/31310e373f4c8c74e029d4326b283e757edabc0b","https://git.kernel.org/stable/c/66df065b3106964e667b37bf8f7e55ec69d0c1f6","https://git.kernel.org/stable/c/7b4881da5b19f65709f5c18c1a4d8caa2e496461","https://git.kernel.org/stable/c/8ea8ef5e42173560ac510e92a1cc797ffeea8831","https://git.kernel.org/stable/c/dbff5f0bfb2416b8b55c105ddbcd4f885e98fada","https://git.kernel.org/stable/c/e60b613df8b6253def41215402f72986fee3fc8d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41087 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix double free on error If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump to the err_out label, which will call devres_release_group(). devres_release_group() will trigger a call to ata_host_release(). ata_host_release() calls kfree(host), so executing the kfree(host) in ata_host_alloc() will lead to a double free: kernel BUG at mm/slub.c:553! Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:kfree+0x2cf/0x2f0 Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246 RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320 RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0 RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780 R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006 FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x6a/0x90 ? kfree+0x2cf/0x2f0 ? exc_invalid_op+0x50/0x70 ? kfree+0x2cf/0x2f0 ? asm_exc_invalid_op+0x1a/0x20 ? ata_host_alloc+0xf5/0x120 [libata] ? ata_host_alloc+0xf5/0x120 [libata] ? kfree+0x2cf/0x2f0 ata_host_alloc+0xf5/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Ensure that we will not call kfree(host) twice, by performing the kfree() only if the devres_open_group() call failed. | ["https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe","https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3","https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2","https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f","https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047","https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5","https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76","https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d","https://git.kernel.org/stable/c/010de9acbea58fbcbda08e3793d6262086a493fe","https://git.kernel.org/stable/c/062e256516d7db5e7dcdef117f52025cd5c456e3","https://git.kernel.org/stable/c/290073b2b557e4dc21ee74a1e403d9ae79e393a2","https://git.kernel.org/stable/c/56f1c7e290cd6c69c948fcd2e2a49e6a637ec38f","https://git.kernel.org/stable/c/5dde5f8b790274723640d29a07c5a97d57d62047","https://git.kernel.org/stable/c/702c1edbafb2e6f9d20f6d391273b5be09d366a5","https://git.kernel.org/stable/c/8106da4d88bbaed809e023cc8014b766223d6e76","https://git.kernel.org/stable/c/ab9e0c529eb7cafebdd31fe1644524e80a48b05d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39495 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: greybus: Fix use-after-free bug in gb_interface_release due to race condition. In gb_interface_create, &intf->mode_switch_completion is bound with gb_interface_mode_switch_work. Then it will be started by gb_interface_request_mode_switch. Here is the relevant code. if (!queue_work(system_long_wq, &intf->mode_switch_work)) { ... } If we call gb_interface_release to make cleanup, there may be an unfinished work. This function will call kfree to free the object "intf". However, if gb_interface_mode_switch_work is scheduled to run after kfree, it may cause use-after-free error as gb_interface_mode_switch_work will use the object "intf". The possible execution flow that may lead to the issue is as follows: CPU0 CPU1 | gb_interface_create | gb_interface_request_mode_switch gb_interface_release | kfree(intf) (free) | | gb_interface_mode_switch_work | mutex_lock(&intf->mutex) (use) Fix it by canceling the work before kfree. | ["https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445","https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea","https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83","https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce","https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201","https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc","https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9","https://git.kernel.org/stable/c/03ea2b129344152157418929f06726989efc0445","https://git.kernel.org/stable/c/0b8fba38bdfb848fac52e71270b2aa3538c996ea","https://git.kernel.org/stable/c/2b6bb0b4abfd79b8698ee161bb73c0936a2aaf83","https://git.kernel.org/stable/c/5c9c5d7f26acc2c669c1dcf57d1bb43ee99220ce","https://git.kernel.org/stable/c/74cd0a421896b2e07eafe7da4275302bfecef201","https://git.kernel.org/stable/c/9a733d69a4a59c2d08620e6589d823c24be773dc","https://git.kernel.org/stable/c/fb071f5c75d4b1c177824de74ee75f9dd34123b9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26748 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver. | ["https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48","https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8","https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3","https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019","https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3","https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c","https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7","https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48","https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8","https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3","https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019","https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3","https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c","https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26749 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. | ["https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9","https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16","https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3","https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d","https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643","https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6","https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824","https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9","https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16","https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3","https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d","https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643","https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6","https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52906 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mpls: Fix warning during failed attribute validation The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid combination according to the comment above 'struct nla_policy': " Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union " This can trigger the warning [1] in nla_get_range_unsigned() when validation of the attribute fails. Despite being of 'NLA_U32' type, the associated 'min'/'max' fields in the policy are negative as they are aliased by the 'validate' field. Fix by changing the attribute type to 'NLA_BINARY' which is consistent with the above comment and all other users of NLA_POLICY_VALIDATE_FN(). As a result, move the length validation to the validation function. No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0 [1] WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118 nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 Modules linked in: CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117 [...] Call Trace: <TASK> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/2b157c3c5d6b8ddca48d53c9e662032f65af8d61","https://git.kernel.org/stable/c/453277feb41c2235cf2c0de9209eef962c401457","https://git.kernel.org/stable/c/8a97b544b98e44f596219ebb290fd2ba2fd5d644","https://git.kernel.org/stable/c/9e17f99220d111ea031b44153fdfe364b0024ff2","https://git.kernel.org/stable/c/9e2c38827cdc6fdd3bb375c8607fc04d289756f9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43873 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vhost/vsock: always initialize seqpacket_allow There are two issues around seqpacket_allow: 1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized. 2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this). To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features | ["https://git.kernel.org/stable/c/1e1fdcbdde3b7663e5d8faeb2245b9b151417d22","https://git.kernel.org/stable/c/3062cb100787a9ddf45de30004b962035cd497fb","https://git.kernel.org/stable/c/30bd4593669443ac58515e23557dc8cef70d8582","https://git.kernel.org/stable/c/ea558f10fb05a6503c6e655a1b7d81fdf8e5924c","https://git.kernel.org/stable/c/eab96e8716cbfc2834b54f71cc9501ad4eec963b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2019-14899 | High | N/A | A vulnerability was discovered in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android that allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel. | ["http://seclists.org/fulldisclosure/2020/Dec/32","http://seclists.org/fulldisclosure/2020/Jul/23","http://seclists.org/fulldisclosure/2020/Jul/24","http://seclists.org/fulldisclosure/2020/Jul/25","http://seclists.org/fulldisclosure/2020/Nov/20","http://www.openwall.com/lists/oss-security/2020/08/13/2","http://www.openwall.com/lists/oss-security/2020/10/07/3","http://www.openwall.com/lists/oss-security/2021/07/05/1","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14899","https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/","https://support.apple.com/kb/HT211288","https://support.apple.com/kb/HT211289","https://support.apple.com/kb/HT211290","https://support.apple.com/kb/HT211850","https://support.apple.com/kb/HT211931","http://seclists.org/fulldisclosure/2020/Dec/32","http://seclists.org/fulldisclosure/2020/Jul/23","http://seclists.org/fulldisclosure/2020/Jul/24","http://seclists.org/fulldisclosure/2020/Jul/25","http://seclists.org/fulldisclosure/2020/Nov/20","http://www.openwall.com/lists/oss-security/2020/08/13/2","http://www.openwall.com/lists/oss-security/2020/10/07/3","http://www.openwall.com/lists/oss-security/2021/07/05/1","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-14899","https://openvpn.net/security-advisory/no-flaws-found-in-openvpn-software/","https://support.apple.com/kb/HT211288","https://support.apple.com/kb/HT211289","https://support.apple.com/kb/HT211290","https://support.apple.com/kb/HT211850","https://support.apple.com/kb/HT211931"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44982 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: cleanup FB if dpu_format_populate_layout fails If the dpu_format_populate_layout() fails, then FB is prepared, but not cleaned up. This ends up leaking the pin_count on the GEM object and causes a splat during DRM file closure: msm_obj->pin_count WARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc [...] Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 irq event stamp: 129818 hardirqs last enabled at (129817): [<ffffa5f6d953fcc0>] console_unlock+0x118/0x124 hardirqs last disabled at (129818): [<ffffa5f6da7dcf04>] el1_dbg+0x24/0x8c softirqs last enabled at (129808): [<ffffa5f6d94afc18>] handle_softirqs+0x4c8/0x4e8 softirqs last disabled at (129785): [<ffffa5f6d94105e4>] __do_softirq+0x14/0x20 Patchwork: https://patchwork.freedesktop.org/patch/600714/ | ["https://git.kernel.org/stable/c/02193c70723118889281f75b88722b26b58bf4ae","https://git.kernel.org/stable/c/7ecf85542169012765e4c2817cd3be6c2e009962","https://git.kernel.org/stable/c/9b8b65211a880af8fe8330a101e1e239a2d4008f","https://git.kernel.org/stable/c/a3c5815b07f4ee19d0b7e2ddf91ff9f03ecbf27d","https://git.kernel.org/stable/c/bfa1a6283be390947d3649c482e5167186a37016"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26980 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-out-of-bounds in smb2_allocate_rsp_buf If ->ProtocolId is SMB2_TRANSFORM_PROTO_NUM, smb2 request size validation could be skipped. if request size is smaller than sizeof(struct smb2_query_info_req), slab-out-of-bounds read can happen in smb2_allocate_rsp_buf(). This patch allocate response buffer after decrypting transform request. smb3_decrypt_req() will validate transform request size and avoid slab-out-of-bound in smb2_allocate_rsp_buf(). | ["https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085","https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1","https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248","https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20","https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325","https://git.kernel.org/stable/c/0977f89722eceba165700ea384f075143f012085","https://git.kernel.org/stable/c/3160d9734453a40db248487f8204830879c207f1","https://git.kernel.org/stable/c/b80ba648714e6d790d69610cf14656be222d0248","https://git.kernel.org/stable/c/c119f4ede3fa90a9463f50831761c28f989bfb20","https://git.kernel.org/stable/c/da21401372607c49972ea87a6edaafb36a17c325"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42080 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/restrack: Fix potential invalid address access struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them. | ["https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d","https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5","https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9","https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8","https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61","https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d","https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5","https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9","https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8","https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49323 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: fix possible null-ptr-deref in arm_smmu_device_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. | ["https://git.kernel.org/stable/c/3660db29b0305f9a1d95979c7af0f5db6ea99f5d","https://git.kernel.org/stable/c/449fc4561762ad9ad85362d5f01f0d0df397457a","https://git.kernel.org/stable/c/80776a71340f57d6a4952635fc89f0342072f3ca","https://git.kernel.org/stable/c/98dd53a92825747395649f54d23512a13c3ed471","https://git.kernel.org/stable/c/d9ed8af1dee37f181096631fb03729ece98ba816"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49468 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/core: Fix memory leak in __thermal_cooling_device_register() I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888010080000 (size 264312): comm "182", pid 102533, jiffies 4296434960 (age 10.100s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 40 7f 1f b9 ff ff ff ff ........@....... backtrace: [<0000000038b2f4fc>] kmalloc_order_trace+0x1d/0x110 mm/slab_common.c:969 [<00000000ebcb8da5>] __kmalloc+0x373/0x420 include/linux/slab.h:510 [<0000000084137f13>] thermal_cooling_device_setup_sysfs+0x15d/0x2d0 include/linux/slab.h:586 [<00000000352b8755>] __thermal_cooling_device_register+0x332/0xa60 drivers/thermal/thermal_core.c:927 [<00000000fb9f331b>] devm_thermal_of_cooling_device_register+0x6b/0xf0 drivers/thermal/thermal_core.c:1041 [<000000009b8012d2>] max6650_probe.cold+0x557/0x6aa drivers/hwmon/max6650.c:211 [<00000000da0b7e04>] i2c_device_probe+0x472/0xac0 drivers/i2c/i2c-core-base.c:561 If device_register() fails, thermal_cooling_device_destroy_sysfs() need be called to free the memory allocated in thermal_cooling_device_setup_sysfs(). | ["https://git.kernel.org/stable/c/18530bedd221160823f63ccc20dd55c7a03edbcf","https://git.kernel.org/stable/c/21ccc58b671aea924f2481cf5c1cf0ebbfd3552d","https://git.kernel.org/stable/c/3802171f0b5b8b831f4ade5c827547cb323a5bb2","https://git.kernel.org/stable/c/98a160e898c0f4a979af9de3ab48b4b1d42d1dbb","https://git.kernel.org/stable/c/9abdf0c0184230f0cb5c6685aabf33dda89aa9fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49546 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/kexec: fix memory leak of elf header buffer This is reported by kmemleak detector: unreferenced object 0xffffc900002a9000 (size 4096): comm "kexec", pid 14950, jiffies 4295110793 (age 373.951s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00 ..>............. backtrace: [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170 [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160 [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0 [<0000000019afff23>] crash_load_segments+0x260/0x470 [<0000000019ebe95c>] bzImage64_load+0x814/0xad0 [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0 [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0 [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530 [<0000000087c19992>] do_syscall_64+0x3b/0x90 [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae In crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to store elf headers. While it's not freed back to system correctly when kdump kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing x86 specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. And also remove the incorrect elf header buffer freeing code. Before calling arch specific kexec_file loading function, the image instance has been initialized. So 'image->elf_headers' must be NULL. It doesn't make sense to free the elf header buffer in the place. Three different people have reported three bugs about the memory leak on x86_64 inside Redhat. | ["https://git.kernel.org/stable/c/115ee42a4c2f26ba2b4ace2668a3f004621f6833","https://git.kernel.org/stable/c/23cf39dccf7653650701a6f39b119e9116a27f1a","https://git.kernel.org/stable/c/8765a423a87d74ef24ea02b43b2728fe4039f248","https://git.kernel.org/stable/c/b3e34a47f98974d0844444c5121aaff123004e57","https://git.kernel.org/stable/c/f675e3a9189d84a9324ab45b0cb19906c2bc8fcb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48654 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix possible bogus match in nf_osf_find() nf_osf_find() incorrectly returns true on mismatch, this leads to copying uninitialized memory area in nft_osf which can be used to leak stale kernel stack data to userspace. | ["https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8","https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47","https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e","https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764","https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e","https://git.kernel.org/stable/c/559c36c5a8d730c49ef805a72b213d3bba155cc8","https://git.kernel.org/stable/c/5d75fef3e61e797fab5c3fbba88caa74ab92ad47","https://git.kernel.org/stable/c/633c81c0449663f57d4138326d036dc6cfad674e","https://git.kernel.org/stable/c/721ea8ac063d70c2078c4e762212705de6151764","https://git.kernel.org/stable/c/816eab147e5c6f6621922b8515ad9010ceb1735e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52340 | High | fixed |
|
The IPv6 implementation in the Linux kernel before 6.3 has a net/ipv6/route.c max_size threshold that can be consumed easily, e.g., leading to a denial of service (network is unreachable errors) when IPv6 packets are sent in a loop via a raw socket. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=af6d10345ca76670c1b7c37799f0d5576ccef277","https://security.netapp.com/advisory/ntap-20240816-0005/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26993 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. | ["https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c","https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063","https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b","https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17","https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4","https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78","https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957","https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5","https://git.kernel.org/stable/c/43f00210cb257bcb0387e8caeb4b46375d67f30c","https://git.kernel.org/stable/c/57baab0f376bec8f54b0fe6beb8f77a57c228063","https://git.kernel.org/stable/c/5d43e072285e81b0b63cee7189b3357c7768a43b","https://git.kernel.org/stable/c/84bd4c2ae9c3d0a7d3a5c032ea7efff17af17e17","https://git.kernel.org/stable/c/a4c99b57d43bab45225ba92d574a8683f9edc8e4","https://git.kernel.org/stable/c/a90bca2228c0646fc29a72689d308e5fe03e6d78","https://git.kernel.org/stable/c/ac107356aabc362aaeb77463e814fc067a5d3957","https://git.kernel.org/stable/c/f28bba37fe244889b81bb5c508d3f6e5c6e342c5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36270 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: tproxy: bail out if IP has been disabled on the device syzbot reports: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] [..] RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62 Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168 __in_dev_get_rcu() can return NULL, so check for this. | ["https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c","https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d","https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3","https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0","https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03","https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c","https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80","https://git.kernel.org/stable/c/07eeedafc59c45fe5de43958128542be3784764c","https://git.kernel.org/stable/c/10f0af5234dafd03d2b75233428ec3f11cf7e43d","https://git.kernel.org/stable/c/21a673bddc8fd4873c370caf9ae70ffc6d47e8d3","https://git.kernel.org/stable/c/570b4c52096e62fda562448f5760fd0ff06110f0","https://git.kernel.org/stable/c/6fe5af4ff06db3d4d80e07a19356640428159f03","https://git.kernel.org/stable/c/819bfeca16eb9ad647ddcae25e7e12c30612147c","https://git.kernel.org/stable/c/caf3a8afb5ea00db6d5398adf148d5534615fd80"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36286 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() syzbot reported that nf_reinject() could be called without rcu_read_lock() : WARNING: suspicious RCU usage 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not tainted net/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172 stack backtrace: CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> | ["https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a","https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4","https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256","https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5","https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9","https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718","https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec","https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab","https://git.kernel.org/stable/c/215df6490e208bfdd5b3012f5075e7f8736f3e7a","https://git.kernel.org/stable/c/25ea5377e3d2921a0f96ae2551f5ab1b36825dd4","https://git.kernel.org/stable/c/3989b817857f4890fab9379221a9d3f52bf5c256","https://git.kernel.org/stable/c/68f40354a3851df46c27be96b84f11ae193e36c5","https://git.kernel.org/stable/c/8658bd777cbfcb0c13df23d0ea120e70517761b9","https://git.kernel.org/stable/c/8f365564af898819a523f1a8cf5c6ce053e9f718","https://git.kernel.org/stable/c/dc21c6cc3d6986d938efbf95de62473982c98dec","https://git.kernel.org/stable/c/e01065b339e323b3dfa1be217fd89e9b3208b0ab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36489 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tls: fix missing memory barrier in tls_init In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}. CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1) // In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3) In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference. To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot. | ["https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b","https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b","https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302","https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c","https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071","https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b","https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b","https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b","https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302","https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c","https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071","https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36938 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which syzbot reported [1]. [1] BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1: sk_psock_stop_verdict net/core/skmsg.c:1257 [inline] sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843 sk_psock_put include/linux/skmsg.h:459 [inline] sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648 unix_release+0x4b/0x80 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0x68/0x150 net/socket.c:1421 __fput+0x2c1/0x660 fs/file_table.c:422 __fput_sync+0x44/0x60 fs/file_table.c:507 __do_sys_close fs/open.c:1556 [inline] __se_sys_close+0x101/0x1b0 fs/open.c:1541 __x64_sys_close+0x1f/0x30 fs/open.c:1541 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0: sk_psock_data_ready include/linux/skmsg.h:464 [inline] sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline] sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202 unix_read_skb net/unix/af_unix.c:2546 [inline] unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2667 __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674 do_syscall_64+0xd3/0x1d0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 value changed: 0xffffffff83d7feb0 -> 0x0000000000000000 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G W 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Prior to this, commit 4cd12c6065df ("bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()") fixed one NULL pointer similarly due to no protection of saved_data_ready. Here is another different caller causing the same issue because of the same reason. So we should protect it with sk_callback_lock read lock because the writer side in the sk_psock_drop() uses "write_lock_bh(&sk->sk_callback_lock);". To avoid errors that could happen in future, I move those two pairs of lock into the sk_psock_data_ready(), which is suggested by John Fastabend. | ["https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27","https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d","https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365","https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80","https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87","https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973","https://git.kernel.org/stable/c/39dc9e1442385d6e9be0b6491ee488dddd55ae27","https://git.kernel.org/stable/c/5965bc7535fb87510b724e5465ccc1a1cf00916d","https://git.kernel.org/stable/c/6648e613226e18897231ab5e42ffc29e63fa3365","https://git.kernel.org/stable/c/772d5729b5ff0df0d37b32db600ce635b2172f80","https://git.kernel.org/stable/c/b397a0ab8582c533ec0c6b732392f141fc364f87","https://git.kernel.org/stable/c/c0809c128dad4c3413818384eb06a341633db973"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38547 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries The allocation failure of mycs->yuv_scaler_binary in load_video_binaries() is followed with a dereference of mycs->yuv_scaler_binary after the following call chain: sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries() In unload_video_binaries(), it calls to ia_css_binary_unload with argument &pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to the same memory slot as mycs->yuv_scaler_binary. Thus, a null-pointer dereference is triggered. | ["https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb","https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80","https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0","https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e","https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272","https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35","https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069","https://git.kernel.org/stable/c/3b621e9e9e148c0928ab109ac3d4b81487469acb","https://git.kernel.org/stable/c/4b68b861b514a5c09220d622ac3784c0ebac6c80","https://git.kernel.org/stable/c/6482c433863b257b0b9b687c28ce80b89d5f89f0","https://git.kernel.org/stable/c/69b27ff82f87379afeaaea4b2f339032fdd8486e","https://git.kernel.org/stable/c/82c2c85aead3ea3cbceef4be077cf459c5df2272","https://git.kernel.org/stable/c/a1ab99dcc8604afe7e3bccb01b10da03bdd7ea35","https://git.kernel.org/stable/c/cc20c87b04db86c8e3e810bcdca686b406206069"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38590 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Modify the print level of CQE error Too much print may lead to a panic in kernel. Change ibdev_err() to ibdev_err_ratelimited(), and change the printing level of cqe dump to debug level. | ["https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990","https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c","https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43","https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b","https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b","https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55","https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd","https://git.kernel.org/stable/c/06cf121346bbd3d83a5eea05bb87666c6b279990","https://git.kernel.org/stable/c/17f3741c65c4a042ae8ba094068b07a4b77e213c","https://git.kernel.org/stable/c/349e859952285ab9689779fb46de163f13f18f43","https://git.kernel.org/stable/c/45b31be4dd22827903df15c548b97b416790139b","https://git.kernel.org/stable/c/6f541a89ced8305da459e3ab0006e7528cf7da7b","https://git.kernel.org/stable/c/817a10a6df9354e67561922d2b7fce48dfbebc55","https://git.kernel.org/stable/c/cc699b7eb2bc963c12ffcd37f80f45330d2924bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38633 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: max3100: Update uart_driver_registered on driver removal The removal of the last MAX3100 device triggers the removal of the driver. However, code doesn't update the respective global variable and after insmod — rmmod — insmod cycle the kernel oopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0 Update the actual state so next time UART driver will be registered again. Hugo also noticed, that the error path in the probe also affected by having the variable set, and not cleared. Instead of clearing it move the assignment after the successfull uart_register_driver() call. | ["https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b","https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752","https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec","https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003","https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00","https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762","https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72","https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0","https://git.kernel.org/stable/c/21a61a7fbcfdd3493cede43ebc7c4dfae2147a8b","https://git.kernel.org/stable/c/361a92c9038e8c8c3996f8eeaa14522a8ad90752","https://git.kernel.org/stable/c/712a1fcb38dc7cac6da63ee79a88708fbf9c45ec","https://git.kernel.org/stable/c/9db4222ed8cd3e50b81c8b910ae74c26427a4003","https://git.kernel.org/stable/c/b6eb7aff23e05f362e8c9b560f6ac5e727b70e00","https://git.kernel.org/stable/c/e8a10089eddba40d4b2080c9d3fc2d2b2488f762","https://git.kernel.org/stable/c/e8e2a4339decad7e59425b594a98613402652d72","https://git.kernel.org/stable/c/fa84ca78b048dfb00df0ef446f5c35e0a98ca6a0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39475 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Handle err return when savagefb_check_var failed The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. | ["https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b","https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089","https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95","https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339","https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547","https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8","https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7","https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3","https://git.kernel.org/stable/c/32f92b0078ebf79dbe4827288e0acb50d89d3d5b","https://git.kernel.org/stable/c/4b2c67e30b4e1d2ae19dba8b8e8f3b5fd3cf8089","https://git.kernel.org/stable/c/5f446859bfa46df0ffb34149499f48a2c2d8cd95","https://git.kernel.org/stable/c/6ad959b6703e2c4c5d7af03b4cfd5ff608036339","https://git.kernel.org/stable/c/86435f39c18967cdd937d7a49ba539cdea7fb547","https://git.kernel.org/stable/c/b8385ff814ca4cb7e63789841e6ec2a14c73e1e8","https://git.kernel.org/stable/c/be754cbd77eaf2932408a4e18532e4945274a5c7","https://git.kernel.org/stable/c/edaa57480b876e8203b51df7c3d14a51ea6b09e3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39482 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bcache: fix variable length array abuse in btree_iter btree_iter is used in two ways: either allocated on the stack with a fixed size MAX_BSETS, or from a mempool with a dynamic size based on the specific cache set. Previously, the struct had a fixed-length array of size MAX_BSETS which was indexed out-of-bounds for the dynamically-sized iterators, which causes UBSAN to complain. This patch uses the same approach as in bcachefs's sort_iter and splits the iterator into a btree_iter with a flexible array member and a btree_iter_stack which embeds a btree_iter as well as a fixed-length data array. | ["https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671","https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b","https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31","https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023","https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148","https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02","https://git.kernel.org/stable/c/0c31344e22dd8d6b1394c6e4c41d639015bdc671","https://git.kernel.org/stable/c/2c3d7b03b658dc8bfa6112b194b67b92a87e081b","https://git.kernel.org/stable/c/3a861560ccb35f2a4f0a4b8207fa7c2a35fc7f31","https://git.kernel.org/stable/c/5a1922adc5798b7ec894cd3f197afb6f9591b023","https://git.kernel.org/stable/c/6479b9f41583b013041943c4602e1ad61cec8148","https://git.kernel.org/stable/c/934e1e4331859183a861f396d7dfaf33cb5afb02"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39489 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix memleak in seg6_hmac_init_algo seg6_hmac_init_algo returns without cleaning up the previous allocations if one fails, so it's going to leak all that memory and the crypto tfms. Update seg6_hmac_exit to only free the memory when allocated, so we can reuse the code directly. | ["https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6","https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3","https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821","https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c","https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976","https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be","https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6","https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383","https://git.kernel.org/stable/c/0e44d6cbe8de983470c3d2f978649783384fdcb6","https://git.kernel.org/stable/c/4a3fcf53725b70010d1cf869a2ba549fed6b8fb3","https://git.kernel.org/stable/c/599a5654215092ac22bfc453f4fd3959c55ea821","https://git.kernel.org/stable/c/61d31ac85b4572d11f8071855c0ccb4f32d76c0c","https://git.kernel.org/stable/c/afd5730969aec960a2fee4e5ee839a6014643976","https://git.kernel.org/stable/c/daf341e0a2318b813427d5a78788c86f4a7f02be","https://git.kernel.org/stable/c/efb9f4f19f8e37fde43dfecebc80292d179f56c6","https://git.kernel.org/stable/c/f6a99ef4e056c20a138a95cc51332b2b96c8f383"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39506 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2","https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa","https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c","https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349","https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347","https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79","https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee","https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea","https://git.kernel.org/stable/c/87d6bdc006f0cbf297a3b2ad6e40ede4c3ee5dc2","https://git.kernel.org/stable/c/a6f4d0ec170a46b5f453cacf55dff5989b42bbfa","https://git.kernel.org/stable/c/a86490a3712cc513113440a606a0e77130abd47c","https://git.kernel.org/stable/c/c44711b78608c98a3e6b49ce91678cd0917d5349","https://git.kernel.org/stable/c/cbf18d8128a753cb632bef39470d19befd9c7347","https://git.kernel.org/stable/c/dcc7440f32c7a26b067aff6e7d931ec593024a79","https://git.kernel.org/stable/c/f1ab15a09492a5ae8ab1e2c35ba2cf9e150d25ee","https://git.kernel.org/stable/c/fd2b613bc4c508e55c1221c6595bb889812a4fea"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40945 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu: Return right value in iommu_sva_bind_device() iommu_sva_bind_device() should return either a sva bond handle or an ERR_PTR value in error cases. Existing drivers (idxd and uacce) only check the return value with IS_ERR(). This could potentially lead to a kernel NULL pointer dereference issue if the function returns NULL instead of an error pointer. In reality, this doesn't cause any problems because iommu_sva_bind_device() only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA. In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will return an error, and the device drivers won't call iommu_sva_bind_device() at all. | ["https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998","https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e","https://git.kernel.org/stable/c/6325eab6c108fed27f60ff51852e3eac0ba23f3f","https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8","https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6","https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e","https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e","https://git.kernel.org/stable/c/2973b8e7d127754de9013177c41c0b5547406998","https://git.kernel.org/stable/c/61a96da9649a6b6a1a5d5bde9374b045fdb5c12e","https://git.kernel.org/stable/c/700f564758882db7c039dfba9443fe762561a3f8","https://git.kernel.org/stable/c/7388ae6f26c0ba95f70cc96bf9c5d5cb06c908b6","https://git.kernel.org/stable/c/89e8a2366e3bce584b6c01549d5019c5cda1205e","https://git.kernel.org/stable/c/cf34f8f66982a36e5cba0d05781b21ec9606b91e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41077 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check] | ["https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7","https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e","https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1","https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0","https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053","https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3","https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7","https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e","https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1","https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0","https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053","https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42101 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes In nouveau_connector_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef","https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d","https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9","https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e","https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4","https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e","https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a","https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07","https://git.kernel.org/stable/c/1f32535238493008587a8c5cb17eb2ca097592ef","https://git.kernel.org/stable/c/274cba8d2d1b48c72d8bd90e76c9e2dc1aa0a81d","https://git.kernel.org/stable/c/744b229f09134ccd091427a6f9ea6d97302cfdd9","https://git.kernel.org/stable/c/7db5411c5d0bd9c29b8c2ad93c36b5c16ea46c9e","https://git.kernel.org/stable/c/80bec6825b19d95ccdfd3393cf8ec15ff2a749b4","https://git.kernel.org/stable/c/9baf60323efa992b7c915094529f0a1882c34e7e","https://git.kernel.org/stable/c/e36364f5f3785d054a94e57e971385284886d41a","https://git.kernel.org/stable/c/f48dd3f19614022f2e1b794fbd169d2b4c398c07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42106 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: inet_diag: Initialize pad field in struct inet_diag_req_v2 KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw sockets uses the pad field in struct inet_diag_req_v2 for the underlying protocol. This field corresponds to the sdiag_raw_protocol field in struct inet_diag_req_raw. inet_diag_get_exact_compat() converts inet_diag_req to inet_diag_req_v2, but leaves the pad field uninitialized. So the issue occurs when raw_lookup() accesses the sdiag_raw_protocol field. Fix this by initializing the pad field in inet_diag_get_exact_compat(). Also, do the same fix in inet_diag_dump_compat() to avoid the similar issue in the future. [1] BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline] BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Local variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 | ["https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2","https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f","https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9","https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c","https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4","https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a","https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb","https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051","https://git.kernel.org/stable/c/0184bf0a349f4cf9e663abbe862ff280e8e4dfa2","https://git.kernel.org/stable/c/61cf1c739f08190a4cbf047b9fbb192a94d87e3f","https://git.kernel.org/stable/c/7094a5fd20ab66028f1da7f06e0f2692d70346f9","https://git.kernel.org/stable/c/76965648fe6858db7c5f3c700fef7aa5f124ca1c","https://git.kernel.org/stable/c/7ef519c8efde152e0d632337f2994f6921e0b7e4","https://git.kernel.org/stable/c/8366720519ea8d322a20780debdfd23d9fc0904a","https://git.kernel.org/stable/c/d6f487e0704de2f2d15f8dd5d7d723210f2b2fdb","https://git.kernel.org/stable/c/f9b2010e8af49fac9d9562146fb81744d8a9b051"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35947 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dyndbg: fix old BUG_ON in >control parser Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead. | ["https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c","https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081","https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38","https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b","https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0","https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab","https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc","https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561","https://git.kernel.org/stable/c/00e7d3bea2ce7dac7bee1cf501fb071fd0ea8f6c","https://git.kernel.org/stable/c/343081c21e56bd6690d342e2f5ae8c00183bf081","https://git.kernel.org/stable/c/3c718bddddca9cbef177ac475b94c5c91147fb38","https://git.kernel.org/stable/c/41d8ac238ab1cab01a8c71798d61903304f4e79b","https://git.kernel.org/stable/c/529e1852785599160415e964ca322ee7add7aef0","https://git.kernel.org/stable/c/a66c869b17c4c4dcf81d273b02cb0efe88e127ab","https://git.kernel.org/stable/c/a69e1bdd777ce51061111dc419801e8a2fd241cc","https://git.kernel.org/stable/c/ba3c118cff7bcb0fe6aa84ae1f9080d50e31c561","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OTB4HWU2PTVW5NEYHHLOCXDKG3PYA534/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35247 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fpga: region: add owner module and take its refcount The current implementation of the fpga region assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the region during programming if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_region struct and use it to take the module's refcount. Modify the functions for registering a region to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the region as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a region without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga region. | ["https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019","https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702","https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8","https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093","https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8","https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9","https://git.kernel.org/stable/c/2279c09c36165ccded4d506d11a7714e13b56019","https://git.kernel.org/stable/c/26e6e25d742e29885cf44274fcf6b744366c4702","https://git.kernel.org/stable/c/4d7d12b643c00e7eea51b49a60a2ead182633ec8","https://git.kernel.org/stable/c/75a001914a8d2ccdcbe4b8cc7e94ac71d0e66093","https://git.kernel.org/stable/c/9b4eee8572dcf82b2ed17d9a328c7fb87df2f0e8","https://git.kernel.org/stable/c/b7c0e1ecee403a43abc89eb3e75672b01ff2ece9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27015 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: incorrect pppoe tuple pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path. | ["https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d","https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27","https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d","https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56","https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2","https://git.kernel.org/stable/c/4ed82dd368ad883dc4284292937b882f044e625d","https://git.kernel.org/stable/c/6db5dc7b351b9569940cd1cf445e237c42cd6d27","https://git.kernel.org/stable/c/e3f078103421642fcd5f05c5e70777feb10f000d","https://git.kernel.org/stable/c/e719b52d0c56989b0f3475a03a6d64f182c85b56","https://git.kernel.org/stable/c/f1c3c61701a0b12f4906152c1626a5de580ea3d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27016 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: validate pppoe header Ensure there is sufficient room to access the protocol field of the PPPoe header. Validate it once before the flowtable lookup, then use a helper function to access protocol field. | ["https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf","https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7","https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9","https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163","https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433","https://git.kernel.org/stable/c/87b3593bed1868b2d9fe096c01bcdf0ea86cbebf","https://git.kernel.org/stable/c/8bf7c76a2a207ca2b4cfda0a279192adf27678d7","https://git.kernel.org/stable/c/a2471d271042ea18e8a6babc132a8716bb2f08b9","https://git.kernel.org/stable/c/cf366ee3bc1b7d1c76a882640ba3b3f8f1039163","https://git.kernel.org/stable/c/d06977b9a4109f8738bb276125eb6a0b772bc433"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48843 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vrr: Set VRR capable prop only if it is attached to connector VRR capable property is not attached by default to the connector It is attached only if VRR is supported. So if the driver tries to call drm core set prop function without it being attached that causes NULL dereference. | ["https://git.kernel.org/stable/c/0ba557d330946c23559aaea2d51ea649fdeca98a","https://git.kernel.org/stable/c/3534c5c005ef99a1804ed50b8a72cdae254cabb5","https://git.kernel.org/stable/c/62929726ef0ec72cbbe9440c5d125d4278b99894","https://git.kernel.org/stable/c/85271e92ae4f13aa679acaa6cf76b3c36bcb7bab","https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779","https://git.kernel.org/stable/c/0ba557d330946c23559aaea2d51ea649fdeca98a","https://git.kernel.org/stable/c/3534c5c005ef99a1804ed50b8a72cdae254cabb5","https://git.kernel.org/stable/c/62929726ef0ec72cbbe9440c5d125d4278b99894","https://git.kernel.org/stable/c/85271e92ae4f13aa679acaa6cf76b3c36bcb7bab","https://git.kernel.org/stable/c/941e8bcd2b2ba95490738e33dfeca27168452779"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52815 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/vkms: fix a possible null pointer dereference In amdgpu_vkms_conn_get_modes(), the return value of drm_cvt_mode() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_cvt_mode(). Add a check to avoid null pointer dereference. | ["https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f","https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a","https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34","https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c","https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27","https://git.kernel.org/stable/c/33fb1a555354bd593f785935ddcb5d9dd4d3847f","https://git.kernel.org/stable/c/70f831f21155c692bb336c434936fd6f24f3f81a","https://git.kernel.org/stable/c/8c6c85a073768df68c1a3fea143d013a38c66d34","https://git.kernel.org/stable/c/cd90511557fdfb394bb4ac4c3b539b007383914c","https://git.kernel.org/stable/c/eaa03ea366c85ae3cb69c8d4bbc67c8bc2167a27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36897 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Atom Integrated System Info v2_2 for DCN35 New request from KMD/VBIOS in order to support new UMA carveout model. This fixes a null dereference from accessing Ctx->dc_bios->integrated_info while it was NULL. DAL parses through the BIOS and extracts the necessary integrated_info but was missing a case for the new BIOS version 2.3. | ["https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c","https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a","https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b","https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60","https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0","https://git.kernel.org/stable/c/02f5300f6827206f6e48a77f51e6264993695e5c","https://git.kernel.org/stable/c/3c7013a87124bab54216d9b99f77e8b6de6fbc1a","https://git.kernel.org/stable/c/7e3030774431eb093165a31baff040d35446fb8b","https://git.kernel.org/stable/c/9a35d205f466501dcfe5625ca313d944d0ac2d60","https://git.kernel.org/stable/c/c2797ec16d9072327e7578d09ee05bcab52fffd0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41093 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: avoid using null object of framebuffer Instead of using state->fb->obj[0] directly, get object from framebuffer by calling drm_gem_fb_get_obj() and return error code when object is null to avoid using null object of framebuffer. | ["https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800","https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447","https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc","https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb","https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46","https://git.kernel.org/stable/c/330c8c1453848c04d335bad81371a66710210800","https://git.kernel.org/stable/c/6ce0544cabaa608018d5922ab404dc656a9d8447","https://git.kernel.org/stable/c/7f35e01cb0ea4d295f5c067bb5c67dfcddaf05bc","https://git.kernel.org/stable/c/bcfa48ff785bd121316592b131ff6531e3e696bb","https://git.kernel.org/stable/c/dd9ec0ea4cdde0fc48116e63969fc83e81d7ef46"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49400 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: Don't set mddev private to NULL in raid0 pers->free In normal stop process, it does like this: do_md_stop | __md_stop (pers->free(); mddev->private=NULL) | md_free (free mddev) __md_stop sets mddev->private to NULL after pers->free. The raid device will be stopped and mddev memory is free. But in reshape, it doesn't free the mddev and mddev will still be used in new raid. In reshape, it first sets mddev->private to new_pers and then runs old_pers->free(). Now raid0 sets mddev->private to NULL in raid0_free. The new raid can't work anymore. It will panic when dereference mddev->private because of NULL pointer dereference. It can panic like this: [63010.814972] kernel BUG at drivers/md/raid10.c:928! [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1 [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020 [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10] [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246 [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000 [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800 [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000 [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200 [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003 [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000 [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0 [63010.927363] Call Trace: [63010.929822] ? bio_reset+0xe/0x40 [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10] [63010.938629] raid10_sync_request+0x756/0x1610 [raid10] [63010.943770] md_do_sync.cold+0x3e4/0x94c [63010.947698] md_thread+0xab/0x160 [63010.951024] ? md_write_inc+0x50/0x50 [63010.954688] kthread+0x149/0x170 [63010.957923] ? set_kthread_struct+0x40/0x40 [63010.962107] ret_from_fork+0x22/0x30 Removing the code that sets mddev->private to NULL in raid0 can fix problem. | ["https://git.kernel.org/stable/c/0f2571ad7a30ff6b33cde142439f9378669f8b4f","https://git.kernel.org/stable/c/7da3454a65f8a56e65dfb44fa0ccac08cbc2f5a1","https://git.kernel.org/stable/c/b7a51df785031cc49caf1c59766ca89cfa97b54b","https://git.kernel.org/stable/c/f63fd1e0e0fc158023cc67ea6a07e278019061ba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52846 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hsr: Prevent use after free in prp_create_tagged_frame() The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value. | ["https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18","https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db","https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d","https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da","https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363","https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd","https://git.kernel.org/stable/c/1787b9f0729d318d67cf7c5a95f0c3dba9a7cc18","https://git.kernel.org/stable/c/6086258bd5ea7b5c706ff62da42b8e271b2401db","https://git.kernel.org/stable/c/876f8ab52363f649bcc74072157dfd7adfbabc0d","https://git.kernel.org/stable/c/a1a485e45d24b1cd8fe834fd6f1b06e2903827da","https://git.kernel.org/stable/c/d103fb6726904e353b4773188ee3d3acb4078363","https://git.kernel.org/stable/c/ddf4e04e946aaa6c458b8b6829617cc44af2bffd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52854 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: padata: Fix refcnt handling in padata_free_shell() In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead to system UAF (Use-After-Free) issues. Due to the lengthy analysis of the pcrypt_aead01 function call, I'll describe the problem scenario using a simplified model: Suppose there's a user of padata named `user_function` that adheres to the padata requirement of calling `padata_free_shell` after `serial()` has been invoked, as demonstrated in the following code: ```c struct request { struct padata_priv padata; struct completion *done; }; void parallel(struct padata_priv *padata) { do_something(); } void serial(struct padata_priv *padata) { struct request *request = container_of(padata, struct request, padata); complete(request->done); } void user_function() { DECLARE_COMPLETION(done) padata->parallel = parallel; padata->serial = serial; padata_do_parallel(); wait_for_completion(&done); padata_free_shell(); } ``` In the corresponding padata.c file, there's the following code: ```c static void padata_serial_worker(struct work_struct *serial_work) { ... cnt = 0; while (!list_empty(&local_list)) { ... padata->serial(padata); cnt++; } local_bh_enable(); if (refcount_sub_and_test(cnt, &pd->refcnt)) padata_free_pd(pd); } ``` Because of the high system load and the accumulation of unexecuted softirq at this moment, `local_bh_enable()` in padata takes longer to execute than usual. Subsequently, when accessing `pd->refcnt`, `pd` has already been released by `padata_free_shell()`, resulting in a UAF issue with `pd->refcnt`. The fix is straightforward: add `refcount_dec_and_test` before calling `padata_free_pd` in `padata_free_shell`. | ["https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5","https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b","https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f","https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d","https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f","https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275","https://git.kernel.org/stable/c/0dd34a7ad395dbcf6ae60e48e9786050e25b9bc5","https://git.kernel.org/stable/c/1734a79e951914f1db2c65e635012a35db1c674b","https://git.kernel.org/stable/c/1e901bcb8af19416b65f5063a4af7996e5a51d7f","https://git.kernel.org/stable/c/41aad9d6953984d134fc50f631f24ef476875d4d","https://git.kernel.org/stable/c/7ddc21e317b360c3444de3023bcc83b85fabae2f","https://git.kernel.org/stable/c/c7c26d0ef5d20f00dbb2ae3befcabbe0efa77275"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38555 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Discard command completions in internal error Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually. Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40 | ["https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb","https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7","https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0","https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a","https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396","https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40","https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3","https://git.kernel.org/stable/c/1337ec94bc5a9eed250e33f5f5c89a28a6bfabdb","https://git.kernel.org/stable/c/1d5dce5e92a70274de67a59e1e674c3267f94cd7","https://git.kernel.org/stable/c/3cb92b0ad73d3f1734e812054e698d655e9581b0","https://git.kernel.org/stable/c/7ac4c69c34240c6de820492c0a28a0bd1494265a","https://git.kernel.org/stable/c/bf8aaf0ae01c27ae3c06aa8610caf91e50393396","https://git.kernel.org/stable/c/db9b31aa9bc56ff0d15b78f7e827d61c4a096e40","https://git.kernel.org/stable/c/f6fbb8535e990f844371086ab2c1221f71f993d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38627 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: stm class: Fix a double free in stm_register_device() The put_device(&stm->dev) call will trigger stm_device_release() which frees "stm" so the vfree(stm) on the next line is a double free. | ["https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20","https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459","https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247","https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931","https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b","https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36","https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695","https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be","https://git.kernel.org/stable/c/370c480410f60b90ba3e96abe73ead21ec827b20","https://git.kernel.org/stable/c/3df463865ba42b8f88a590326f4c9ea17a1ce459","https://git.kernel.org/stable/c/4bfd48bb6e62512b9c392c5002c11e1e3b18d247","https://git.kernel.org/stable/c/6cc30ef8eb6d8f8d6df43152264bbf8835d99931","https://git.kernel.org/stable/c/713fc00c571dde4af3db2dbd5d1b0eadc327817b","https://git.kernel.org/stable/c/7419df1acffbcc90037f6b5a2823e81389659b36","https://git.kernel.org/stable/c/a0450d3f38e7c6c0a7c0afd4182976ee15573695","https://git.kernel.org/stable/c/d782a2db8f7ac49c33b9ca3e835500a28667d1be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41011 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: don't allow mapping the MMIO HDP page with large pages We don't get the right offset in that case. The GPU has an unused 4K area of the register BAR space into which you can remap registers. We remap the HDP flush registers into this space to allow userspace (CPU or GPU) to flush the HDP when it updates VRAM. However, on systems with >4K pages, we end up exposing PAGE_SIZE of MMIO space. | ["https://git.kernel.org/stable/c/009c4d78bcf07c4ac2e3dd9f275b4eaa72b4f884","https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724","https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5","https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28","https://git.kernel.org/stable/c/8ad4838040e5515939c071a0f511ce2661a0889d","https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7","https://git.kernel.org/stable/c/f7276cdc1912325b64c33fcb1361952c06e55f63","https://git.kernel.org/stable/c/4b4cff994a27ebf7bd3fb9a798a1cdfa8d01b724","https://git.kernel.org/stable/c/6186c93560889265bfe0914609c274eff40bbeb5","https://git.kernel.org/stable/c/89fffbdf535ce659c1a26b51ad62070566e33b28","https://git.kernel.org/stable/c/be4a2a81b6b90d1a47eaeaace4cc8e2cb57b96c7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41046 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix double free in detach The number of the currently released descriptor is never incremented which results in the same skb being released multiple times. | ["https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec","https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1","https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156","https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f","https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1","https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54","https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3","https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69","https://git.kernel.org/stable/c/1a2db00a554cfda57c397cce79b2804bf9633fec","https://git.kernel.org/stable/c/22b16618a80858b3a9d607708444426948cc4ae1","https://git.kernel.org/stable/c/69ad5fa0ce7c548262e0770fc2b726fe7ab4f156","https://git.kernel.org/stable/c/84aaaa796a19195fc59290154fef9aeb1fba964f","https://git.kernel.org/stable/c/907443174e76b854d28024bd079f0e53b94dc9a1","https://git.kernel.org/stable/c/9d23909ae041761cb2aa0c3cb1748598d8b6bc54","https://git.kernel.org/stable/c/c2b66e2b3939af63699e4a4bd25a8ac4a9b1d1b3","https://git.kernel.org/stable/c/e1533b6319ab9c3a97dad314dd88b3783bc41b69"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42148 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bnx2x: Fix multiple UBSAN array-index-out-of-bounds Fix UBSAN warnings that occur when using a system with 32 physical cpu cores or more, or when the user defines a number of Ethernet queues greater than or equal to FP_SB_MAX_E1x using the num_queues module parameter. Currently there is a read/write out of bounds that occurs on the array "struct stats_query_entry query" present inside the "bnx2x_fw_stats_req" struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h". Looking at the definition of the "struct stats_query_entry query" array: struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX]; FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3 meaning the array has a total size of 19. Since accesses to "struct stats_query_entry query" are offset-ted by BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet queues should not exceed FP_SB_MAX_E1x (16). However one of these queues is reserved for FCOE and thus the number of Ethernet queues should be set to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if it is not. This is also described in a comment in the source code in drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition of FP_SB_MAX_E1x. Below is the part of this explanation that it important for this patch /* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */ However this driver also supports NICs that use the E2 controller which can handle more queues due to having more FP-SB represented by FP_SB_MAX_E2. Looking at the commits when the E2 support was added, it was originally using the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support"). Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver was later updated to take full advantage of the E2 instead of having it be limited to the capabilities of the E1x. But as far as we can tell, the array "stats_query_entry query" was still limited to using the FP-SB available to the E1x cards as part of an oversignt when the driver was updated to take full advantage of the E2, and now with the driver being aware of the greater queue size supported by E2 NICs, it causes the UBSAN warnings seen in the stack traces below. This patch increases the size of the "stats_query_entry query" array by replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle both types of NICs. Stack traces: UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11 index 20 is out of range for type 'stats_query_entry [19]' CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133 Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated--- | ["https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b","https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7","https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f","https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce","https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d","https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f","https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e","https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98","https://git.kernel.org/stable/c/0edae06b4c227bcfaf3ce21208d49191e1009d3b","https://git.kernel.org/stable/c/134061163ee5ca4759de5c24ca3bd71608891ba7","https://git.kernel.org/stable/c/8b17cec33892a66bbd71f8d9a70a45e2072ae84f","https://git.kernel.org/stable/c/9504a1550686f53b0bab4cab31d435383b1ee2ce","https://git.kernel.org/stable/c/b9ea38e767459111a511ed4fb74abc37db95a59d","https://git.kernel.org/stable/c/cbe53087026ad929cd3950508397e8892a6a2a0f","https://git.kernel.org/stable/c/cfb04472ce33bee2579caf4dc9f4242522f6e26e","https://git.kernel.org/stable/c/f1313ea92f82451923e28ab45a4aaa0e70e80b98"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48637 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bnxt: prevent skb UAF after handing over to PTP worker When reading the timestamp is required bnxt_tx_int() hands over the ownership of the completed skb to the PTP worker. The skb should not be used afterwards, as the worker may run before the rest of our code and free the skb, leading to a use-after-free. Since dev_kfree_skb_any() accepts NULL make the loss of ownership more obvious and set skb to NULL. | ["https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6","https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338","https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65","https://git.kernel.org/stable/c/08483e4c0c83b221b8891434a04cec405dee94a6","https://git.kernel.org/stable/c/32afa1f23e42cc635ccf4c39f24514d03d1e8338","https://git.kernel.org/stable/c/c31f26c8f69f776759cbbdfb38e40ea91aa0dd65"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52751 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free in smb2_query_info_compound() The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] This is a race between open_cached_dir() and cached_dir_lease_break() where the cache entry for the open directory handle receives a lease break while creating it. And before returning from open_cached_dir(), we put the last reference of the new @cfid because of !@cfid->has_lease. Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ... To fix both, in open_cached_dir() ensure that @cfid->has_lease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid. And, if open failed for some reason, re-check @cfid->has_lease to decide whether or not put lease reference. | ["https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b","https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9","https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f","https://git.kernel.org/stable/c/5c86919455c1edec99ebd3338ad213b59271a71b","https://git.kernel.org/stable/c/6db94d08359c43f2c8fe372811cdee04564a41b9","https://git.kernel.org/stable/c/93877b9afc2994c89362007aac480a7b150f386f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35887 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ax25: fix use-after-free bugs caused by ax25_ds_del_timer When the ax25 device is detaching, the ax25_dev_device_down() calls ax25_ds_del_timer() to cleanup the slave_timer. When the timer handler is running, the ax25_ds_del_timer() that calls del_timer() in it will return directly. As a result, the use-after-free bugs could happen, one of the scenarios is shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout() ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USE In order to mitigate bugs, when the device is detaching, use timer_shutdown_sync() to stop the timer. | ["https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b","https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9","https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89","https://git.kernel.org/stable/c/74204bf9050f7627aead9875fe4e07ba125cb19b","https://git.kernel.org/stable/c/c6a368f9c7af4c14b14d390c2543af8001c9bdb9","https://git.kernel.org/stable/c/fd819ad3ecf6f3c232a06b27423ce9ed8c20da89"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38630 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen. Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released. | ["https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4","https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314","https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a","https://git.kernel.org/stable/c/573601521277119f2e2ba5f28ae6e87fc594f4d4","https://git.kernel.org/stable/c/9b1c063ffc075abf56f63e55d70b9778ff534314","https://git.kernel.org/stable/c/f19686d616500cd0d47b30cee82392b53f7f784a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42313 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. | ["https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36","https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635","https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d63920c2","https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567","https://git.kernel.org/stable/c/a0157b5aa34eb43ec4c5510f9c260bbb03be937e","https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6","https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad","https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44934 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: bridge: mcast: wait for previous gc cycles when removing port syzbot hit a use-after-free[1] which is caused because the bridge doesn't make sure that all previous garbage has been collected when removing a port. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still running Make sure all previous gc cycles have finished by using flush_work before freeing the port. [1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437 | ["https://git.kernel.org/stable/c/0d8b26e10e680c01522d7cc14abe04c3265a928f","https://git.kernel.org/stable/c/1e16828020c674b3be85f52685e8b80f9008f50f","https://git.kernel.org/stable/c/92c4ee25208d0f35dafc3213cdf355fbe449e078","https://git.kernel.org/stable/c/b2f794b168cf560682ff976b255aa6d29d14a658","https://git.kernel.org/stable/c/e3145ca904fa8dbfd1a5bf0187905bc117b0efce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48956 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid use-after-free in ip6_fragment() Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers. It seems to not be always true, at least for UDP stack. syzbot reported: BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618 CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 ip6_dst_idev include/net/ip6_fib.h:245 [inline] ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 __ip6_finish_output net/ipv6/ip6_output.c:193 [inline] ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206 NF_HOOK_COND include/linux/netfilter.h:291 [inline] ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227 dst_output include/net/dst.h:445 [inline] ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161 ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966 udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286 udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313 udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xd3/0x120 net/socket.c:734 sock_write_iter+0x295/0x3d0 net/socket.c:1108 call_write_iter include/linux/fs.h:2191 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x9ed/0xdd0 fs/read_write.c:584 ksys_write+0x1ec/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000 </TASK> Allocated by task 7618: kasan_save_stack+0x22/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3398 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422 dst_alloc+0x14a/0x1f0 net/core/dst.c:92 ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344 ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline] rt6_make_pcpu_route net/ipv6/route.c:1417 [inline] ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254 pol_lookup_func include/net/ip6_fib.h:582 [inline] fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625 ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638 ip6_route_output include/net/ip6_route.h:98 [inline] ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092 ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222 ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260 udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554 inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665 sock_sendmsg_nosec n ---truncated--- | ["https://git.kernel.org/stable/c/6b6d3be3661bff2746cab26147bd629aa034e094","https://git.kernel.org/stable/c/7390c70bd431cbfa6951477e2c80a301643e284b","https://git.kernel.org/stable/c/7e0dcd5f3ade221a6126278aca60c8ab4cc3bce9","https://git.kernel.org/stable/c/803e84867de59a1e5d126666d25eb4860cfd2ebe","https://git.kernel.org/stable/c/8208d7e56b1e579320b9ff3712739ad2e63e1f86","https://git.kernel.org/stable/c/9b1a468a455d8319041528778d0e684a4c062792","https://git.kernel.org/stable/c/b3d7ff8c04a83279fb7641fc4d5aa82a602df7c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26982 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Squashfs: check the inode number is not the invalid value of zero Syskiller has produced an out of bounds access in fill_meta_index(). That out of bounds access is ultimately caused because the inode has an inode number with the invalid value of zero, which was not checked. The reason this causes the out of bounds access is due to following sequence of events: 1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number). 2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed. This patch adds a sanity check which checks that the inode number is not zero when the inode is created and returns -EINVAL if it is. [phillip@squashfs.org.uk: whitespace fix] | ["https://git.kernel.org/stable/c/32c114a58236fe67141634774559f21f1dc96fd7","https://git.kernel.org/stable/c/4a1b6f89825e267e156ccaeba3d235edcac77f94","https://git.kernel.org/stable/c/5b99dea79650b50909c50aba24fbae00f203f013","https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5","https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395","https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e","https://git.kernel.org/stable/c/cf46f88b92cfc0e32bd8a21ba1273cff13b8745f","https://git.kernel.org/stable/c/7def00ebc9f2d6a581ddf46ce4541f84a10680e5","https://git.kernel.org/stable/c/9253c54e01b6505d348afbc02abaa4d9f8a01395","https://git.kernel.org/stable/c/be383effaee3d89034f0828038f95065b518772e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35937 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: check A-MSDU format more carefully If it looks like there's another subframe in the A-MSDU but the header isn't fully there, we can end up reading data out of bounds, only to discard later. Make this a bit more careful and check if the subframe header can even be present. | ["https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544","https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9","https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc","https://git.kernel.org/stable/c/9eb3bc0973d084423a6df21cf2c74692ff05647e","https://git.kernel.org/stable/c/16da1e1dac23be45ef6e23c41b1508c400e6c544","https://git.kernel.org/stable/c/5d7a8585fbb31e88fb2a0f581b70667d3300d1e9","https://git.kernel.org/stable/c/9ad7974856926129f190ffbe3beea78460b3b7cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43882 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: exec: Fix ToCToU between perm check and set-uid/gid usage When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges. For example, if a file could change permissions from executable and not set-id: ---------x 1 root root 16048 Aug 7 13:16 target to set-id and non-executable: ---S------ 1 root root 16048 Aug 7 13:16 target it is possible to gain root privileges when execution should have been disallowed. While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root: -rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target becomes: -rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root". Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal. | ["https://git.kernel.org/stable/c/15469d46ba34559bfe7e3de6659115778c624759","https://git.kernel.org/stable/c/368f6985d46657b8b466a421dddcacd4051f7ada","https://git.kernel.org/stable/c/90dfbba89ad4f0d9c9744ecbb1adac4aa2ff4f3e","https://git.kernel.org/stable/c/9b424c5d4130d56312e2a3be17efb0928fec4d64","https://git.kernel.org/stable/c/d2a2a4714d80d09b0f8eb6438ab4224690b7121e","https://git.kernel.org/stable/c/d5c3c7e26275a2d83b894d30f7582a42853a958f","https://git.kernel.org/stable/c/f50733b45d865f91db90919f8311e2127ce5a0cb","https://git.kernel.org/stable/c/f6cfc6bcfd5e1cf76115b6450516ea4c99897ae1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checks for 'stream' and 'plane' before dereferencing This commit adds null checks for the 'stream' and 'plane' variables in the dcn30_apply_idle_power_optimizations function. These variables were previously assumed to be null at line 922, but they were used later in the code without checking if they were null. This could potentially lead to a null pointer dereference, which would cause a crash. The null checks ensure that 'stream' and 'plane' are not null before they are used, preventing potential crashes. Fixes the below static smatch checker: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:938 dcn30_apply_idle_power_optimizations() error: we previously assumed 'stream' could be null (see line 922) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:940 dcn30_apply_idle_power_optimizations() error: we previously assumed 'plane' could be null (see line 922) | ["https://git.kernel.org/stable/c/10c20d79d59cadfe572480d98cec271a89ffb024","https://git.kernel.org/stable/c/15c2990e0f0108b9c3752d7072a97d45d4283aea","https://git.kernel.org/stable/c/16a8a2a839d19c4cf7253642b493ffb8eee1d857","https://git.kernel.org/stable/c/5e84eda48ffb2363437db44bbd0235594f8a58f9","https://git.kernel.org/stable/c/fcf9d6a9f30ea414b6b84a6e901cebd44e146847"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-1749 | High | N/A | A flaw was found in the Linux kernel's implementation of some networking protocols in IPsec, such as VXLAN and GENEVE tunnels over IPv6. When an encrypted tunnel is created between two hosts, the kernel isn't correctly routing tunneled data over the encrypted link; rather sending the data unencrypted. This would allow anyone in between the two endpoints to read the traffic unencrypted. The main threat from this vulnerability is to data confidentiality. | ["https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1749","https://security.netapp.com/advisory/ntap-20201222-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-1749","https://security.netapp.com/advisory/ntap-20201222-0001/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3523 | Medium | N/A | A vulnerability was found in Linux Kernel. It has been classified as problematic. Affected is an unknown function of the file mm/memory.c of the component Driver Handler. The manipulation leads to use after free. It is possible to launch the attack remotely. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211020. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ce101db85db694a91380aa4c89b25530871d33","https://vuldb.com/?id.211020","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=16ce101db85db694a91380aa4c89b25530871d33","https://vuldb.com/?id.211020"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48878 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194 | ["https://git.kernel.org/stable/c/272970be3dabd24cbe50e393ffee8f04aec3b9a8","https://git.kernel.org/stable/c/908d1742b6e694e84ead5c62e4b7c1bfbb8b46a3","https://git.kernel.org/stable/c/e84ec6e25df9bb0968599e92eacedaf3a0a5b587","https://git.kernel.org/stable/c/ea3ebda47dd56f6e1c62f2e0e1b6e1b0a973e447"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49085 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drbd: Fix five use after free bugs in get_initial_state In get_initial_state, it calls notify_initial_state_done(skb,..) if cb->args[5]==1. If genlmsg_put() failed in notify_initial_state_done(), the skb will be freed by nlmsg_free(skb). Then get_initial_state will goto out and the freed skb will be used by return value skb->len, which is a uaf bug. What's worse, the same problem goes even further: skb can also be freed in the notify_*_state_change -> notify_*_state calls below. Thus 4 additional uaf bugs happened. My patch lets the problem callee functions: notify_initial_state_done and notify_*_state_change return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid. v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/ | ["https://git.kernel.org/stable/c/0489700bfeb1e53eb2039c2291c67e71b0b40103","https://git.kernel.org/stable/c/188fe6b26765edbad4055611c0f788b6870f4024","https://git.kernel.org/stable/c/226e993c39405292781bfcf4b039a8db56aab362","https://git.kernel.org/stable/c/594205b4936771a250f9d141e7e0fff21c3dd2d9","https://git.kernel.org/stable/c/a972c768723359ec995579902473028fe3cd64b1","https://git.kernel.org/stable/c/aadb22ba2f656581b2f733deb3a467c48cc618f6","https://git.kernel.org/stable/c/b6a4055036eed1f5e239ce3d8b0db1ce38bba447","https://git.kernel.org/stable/c/dcf6be17b5c53b741898d2223b23e66d682de300","https://git.kernel.org/stable/c/de63e74da2333b4068bb79983e632db730fea97e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49114 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix use after free in fc_exch_abts_resp() fc_exch_release(ep) will decrease the ep's reference count. When the reference count reaches zero, it is freed. But ep is still used in the following code, which will lead to a use after free. Return after the fc_exch_release() call to avoid use after free. | ["https://git.kernel.org/stable/c/1d7effe5fff9d28e45e18ac3a564067c7ddfe898","https://git.kernel.org/stable/c/271add11994ba1a334859069367e04d2be2ebdd4","https://git.kernel.org/stable/c/412dd8299b02e4410fe77b8396953c1a8dde183a","https://git.kernel.org/stable/c/499d198494e77b6533251b9b909baf5c101129cb","https://git.kernel.org/stable/c/4a131d4ea8b581ac9b01d3a72754db4848be3232","https://git.kernel.org/stable/c/5cf2ce8967b0d98c8cfa4dc42ef4fcf080f5c836","https://git.kernel.org/stable/c/6044ad64f41c87382cfeeca281573d1886d80cbe","https://git.kernel.org/stable/c/87909291762d08fdb60d19069d7a89b5b308d0ef","https://git.kernel.org/stable/c/f581df412bc45c95176e3c808ee2839c05b2ab0c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35866 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_dump_full_key() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682","https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113","https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045","https://git.kernel.org/stable/c/d798fd98e3563027c5162259ead517057d6fa794","https://git.kernel.org/stable/c/f4a60d360d9114b5085701a3702a0102b0d6d846","https://git.kernel.org/stable/c/10e17ca4000ec34737bde002a13435c38ace2682","https://git.kernel.org/stable/c/3103163ccd3be4adcfa37e15608fb497be044113","https://git.kernel.org/stable/c/58acd1f497162e7d282077f816faa519487be045"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46738 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: VMCI: Fix use-after-free when removing resource in vmci_resource_remove() When removing a resource from vmci_resource_table in vmci_resource_remove(), the search is performed using the resource handle by comparing context and resource fields. It is possible though to create two resources with different types but same handle (same context and resource fields). When trying to remove one of the resources, vmci_resource_remove() may not remove the intended one, but the object will still be freed as in the case of the datagram type in vmci_datagram_destroy_handle(). vmci_resource_table will still hold a pointer to this freed resource leading to a use-after-free vulnerability. BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0 This change ensures the type is also checked when removing the resource from vmci_resource_table in vmci_resource_remove(). | ["https://git.kernel.org/stable/c/00fe5292f081f8d773e572df8e03bf6e1855fe49","https://git.kernel.org/stable/c/39e7e593418ccdbd151f2925fa6be1a616d16c96","https://git.kernel.org/stable/c/48b9a8dabcc3cf5f961b2ebcd8933bf9204babb7","https://git.kernel.org/stable/c/6c563a29857aa8053b67ee141191f69757f27f6e","https://git.kernel.org/stable/c/b243d52b5f6f59f9d39e69b191fb3d58b94a43b1","https://git.kernel.org/stable/c/b9efdf333174468651be40390cbc79c9f55d9cce","https://git.kernel.org/stable/c/ef5f4d0c5ee22d4f873116fec844ff6edaf3fa7d","https://git.kernel.org/stable/c/f6365931bf7c07b2b397dbb06a4f6573cc9fae73"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40994 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ptp: fix integer overflow in max_vclocks_store On 32bit systems, the "4 * max" multiply can overflow. Use kcalloc() to do the allocation to prevent this. | ["https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e","https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f","https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0","https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f","https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e","https://git.kernel.org/stable/c/4b03da87d0b7074c93d9662c6e1a8939f9b8b86e","https://git.kernel.org/stable/c/666e934d749e50a37f3796caaf843a605f115b6f","https://git.kernel.org/stable/c/81d23d2a24012e448f651e007fac2cfd20a45ce0","https://git.kernel.org/stable/c/d50d62d5e6ee6aa03c00bddb91745d0b632d3b0f","https://git.kernel.org/stable/c/e1fccfb4638ee6188377867f6015d0ce35764a8e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52799 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbFindLeaf Currently while searching for dmtree_t for sufficient free blocks there is an array out of bounds while getting element in tp->dm_stree. To add the required check for out of bound we first need to determine the type of dmtree. Thus added an extra parameter to dbFindLeaf so that the type of tree can be determined and the required check can be applied. | ["https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859","https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c","https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61","https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046","https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878","https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514","https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67","https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9","https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2","https://git.kernel.org/stable/c/20f9310a18e3e99fc031e036fcbed67105ae1859","https://git.kernel.org/stable/c/22cad8bc1d36547cdae0eef316c47d917ce3147c","https://git.kernel.org/stable/c/81aa58cd8495b8c3b527f58ccbe19478d8087f61","https://git.kernel.org/stable/c/86df90f3fea7c5591f05c8a0010871d435e83046","https://git.kernel.org/stable/c/87c681ab49e99039ff2dd3e71852417381b13878","https://git.kernel.org/stable/c/88b7894a8f8705bf4e7ea90b10229376abf14514","https://git.kernel.org/stable/c/a50b796d36719757526ee094c703378895ab5e67","https://git.kernel.org/stable/c/da3da5e1e6f71c21d8e6149d7076d936ef5d4cb9","https://git.kernel.org/stable/c/ecfb47f13b08b02cf28b7b50d4941eefa21954d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52805 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diAlloc Currently there is not check against the agno of the iag while allocating new inodes to avoid fragmentation problem. Added the check which is required. | ["https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483","https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8","https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1","https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9","https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641","https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777","https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c","https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d","https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083","https://git.kernel.org/stable/c/05d9ea1ceb62a55af6727a69269a4fd310edf483","https://git.kernel.org/stable/c/1708d0a9917fea579cc9da3d87b154285abd2cd8","https://git.kernel.org/stable/c/1ba7df5457dc1c1071c5f92ac11323533a6430e1","https://git.kernel.org/stable/c/2308d0fb0dc32446b4e6ca37cd09c30374bb64e9","https://git.kernel.org/stable/c/64f062baf202b82f54987a3f614a6c8f3e466641","https://git.kernel.org/stable/c/665b44e55c2767a4f899c3b18f49e9e1c9983777","https://git.kernel.org/stable/c/7467ca10a5ff09b0e87edf6c4d2a4bfdee69cf2c","https://git.kernel.org/stable/c/8c68af2af697ba2ba3b138be0c6d72e2ce3a3d6d","https://git.kernel.org/stable/c/cf7e3e84df36a9953796c737f080712f631d7083"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26957 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix reference counting on zcrypt card objects Tests with hot-plugging crytpo cards on KVM guests with debug kernel build revealed an use after free for the load field of the struct zcrypt_card. The reason was an incorrect reference handling of the zcrypt card object which could lead to a free of the zcrypt card object while it was still in use. This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated--- | ["https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484","https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c","https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd","https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058","https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55","https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6","https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca","https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d","https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000","https://git.kernel.org/stable/c/394b6d8bbdf9ddee6d5bcf3e1f3e9f23eecd6484","https://git.kernel.org/stable/c/50ed48c80fecbe17218afed4f8bed005c802976c","https://git.kernel.org/stable/c/6470078ab3d8f222115e11c4ec67351f3031b3dd","https://git.kernel.org/stable/c/7e500849fa558879a1cde43f80c7c048c2437058","https://git.kernel.org/stable/c/9daddee03de3f231012014dab8ab2b277a116a55","https://git.kernel.org/stable/c/a55677878b93e9ebc31f66d0e2fb93be5e7836a6","https://git.kernel.org/stable/c/a64ab862e84e3e698cd351a87cdb504c7fc575ca","https://git.kernel.org/stable/c/b7f6c3630eb3f103115ab0d7613588064f665d0d","https://git.kernel.org/stable/c/befb7f889594d23e1b475720cf93efd2f77df000","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27395 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: Fix Use-After-Free in ovs_ct_exit Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal of ovs_ct_limit_exit, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. | ["https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994","https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3","https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424","https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2","https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4","https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1","https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137","https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865","https://git.kernel.org/stable/c/2db9a8c0a01fa1c762c1e61a13c212c492752994","https://git.kernel.org/stable/c/35880c3fa6f8fe281a19975d2992644588ca33d3","https://git.kernel.org/stable/c/589523cf0b384164e445dd5db8d5b1bf97982424","https://git.kernel.org/stable/c/5ea7b72d4fac2fdbc0425cd8f2ea33abe95235b2","https://git.kernel.org/stable/c/9048616553c65e750d43846f225843ed745ec0d4","https://git.kernel.org/stable/c/bca6fa2d9a9f560e6b89fd5190b05cc2f5d422c1","https://git.kernel.org/stable/c/eaa5e164a2110d2fb9e16c8a29e4501882235137","https://git.kernel.org/stable/c/edee0758747d7c219e29db9ed1d4eb33e8d32865","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27396 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: gtp: Fix Use-After-Free in gtp_dellink Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal of gtp_dellink, is not part of the RCU read critical section, it is possible that the RCU grace period will pass during the traversal and the key will be free. To prevent this, it should be changed to hlist_for_each_entry_safe. | ["https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58","https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd","https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29","https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6","https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07","https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7","https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474","https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64","https://git.kernel.org/stable/c/07b20d0a3dc13fb1adff10b60021a4924498da58","https://git.kernel.org/stable/c/0caff3e6390f840666b8dc1ecebf985c2ef3f1dd","https://git.kernel.org/stable/c/25a1c2d4b1fcf938356a9688a96a6456abd44b29","https://git.kernel.org/stable/c/2aacd4de45477582993f8a8abb9505a06426bfb6","https://git.kernel.org/stable/c/2e74b3fd6bf542349758f283676dff3660327c07","https://git.kernel.org/stable/c/718df1bc226c383dd803397d7f5d95557eb81ac7","https://git.kernel.org/stable/c/cd957d1716ec979d8f5bf38fc659aeb9fdaa2474","https://git.kernel.org/stable/c/f2a904107ee2b647bb7794a1a82b67740d7c8a64","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35847 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] | ["https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792","https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137","https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438","https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52","https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662","https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91","https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9","https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae","https://git.kernel.org/stable/c/03170e657f62c26834172742492a8cb8077ef792","https://git.kernel.org/stable/c/5b012f77abde89bf0be8a0547636184fea618137","https://git.kernel.org/stable/c/5dbdbe1133911ca7d8466bb86885adec32ad9438","https://git.kernel.org/stable/c/aa44d21574751a7d6bca892eb8e0e9ac68372e52","https://git.kernel.org/stable/c/b72d2b1448b682844f995e660b77f2a1fabc1662","https://git.kernel.org/stable/c/c26591afd33adce296c022e3480dea4282b7ef91","https://git.kernel.org/stable/c/dd681710ab77c8beafe2e263064cb1bd0e2d6ca9","https://git.kernel.org/stable/c/f5417ff561b8ac9a7e53c747b8627a7ab58378ae","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48701 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix an out-of-bounds bug in __snd_usb_parse_audio_interface() There may be a bad USB audio device with a USB ID of (0x04fa, 0x4201) and the number of it's interfaces less than 4, an out-of-bounds read bug occurs when parsing the interface descriptor for this device. Fix this by checking the number of interfaces. | ["https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712","https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936","https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf","https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0","https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251","https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd","https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061","https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf","https://git.kernel.org/stable/c/0492798bf8dfcc09c9337a1ba065da1d1ca68712","https://git.kernel.org/stable/c/2a308e415d247a23d4d64c964c02e782eede2936","https://git.kernel.org/stable/c/6123bec8480d23369e2ee0b2208611619f269faf","https://git.kernel.org/stable/c/8293e61bbf908b18ff9935238d4fc2ad359e3fe0","https://git.kernel.org/stable/c/91904870370fd986c29719846ed76d559de43251","https://git.kernel.org/stable/c/98e8e67395cc6d0cdf3a771f86ea42d0ee6e59dd","https://git.kernel.org/stable/c/b970518014f2f0f6c493fb86c1e092b936899061","https://git.kernel.org/stable/c/e53f47f6c1a56d2af728909f1cb894da6b43d9bf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38429 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/connection.c in ksmbd has an off-by-one error in memory allocation (because of ksmbd_smb2_check_message) that may lead to out-of-bounds access. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/ksmbd?id=443d61d1fa9faa60ef925513d83742902390100f","https://security.netapp.com/advisory/ntap-20250103-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-16119 | High | N/A | Use-after-free vulnerability in the Linux kernel exploitable by a local attacker due to reuse of a DCCP socket with an attached dccps_hc_tx_ccid object as a listener after being released. Fixed in Ubuntu Linux kernel 5.4.0-51.56, 5.3.0-68.63, 4.15.0-121.123, 4.4.0-193.224, 3.13.0.182.191 and 3.2.0-149.196. | ["https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=01872cb896c76cedeabe93a08456976ab55ad695","https://launchpad.net/bugs/1883840","https://lists.debian.org/debian-lts-announce/2021/10/msg00010.html","https://lists.debian.org/debian-lts-announce/2021/12/msg00012.html","https://lore.kernel.org/netdev/20201013171849.236025-1-kleber.souza%40canonical.com/T/","https://security.netapp.com/advisory/ntap-20210304-0006/","https://ubuntu.com/USN-4576-1","https://ubuntu.com/USN-4577-1","https://ubuntu.com/USN-4578-1","https://ubuntu.com/USN-4579-1","https://ubuntu.com/USN-4580-1","https://www.debian.org/security/2021/dsa-4978","https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/focal/commit/?id=01872cb896c76cedeabe93a08456976ab55ad695","https://launchpad.net/bugs/1883840","https://lists.debian.org/debian-lts-announce/2021/10/msg00010.html","https://lists.debian.org/debian-lts-announce/2021/12/msg00012.html","https://lore.kernel.org/netdev/20201013171849.236025-1-kleber.souza%40canonical.com/T/","https://security.netapp.com/advisory/ntap-20210304-0006/","https://ubuntu.com/USN-4576-1","https://ubuntu.com/USN-4577-1","https://ubuntu.com/USN-4578-1","https://ubuntu.com/USN-4579-1","https://ubuntu.com/USN-4580-1","https://www.debian.org/security/2021/dsa-4978"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent NULL dereference in ip6_output() According to syzbot, there is a chance that ip6_dst_idev() returns NULL in ip6_output(). Most places in IPv6 stack deal with a NULL idev just fine, but not here. syzbot reported: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237 Code: 3c 1e 00 49 89 df 74 08 4c 89 ef e8 19 58 db f7 48 8b 44 24 20 49 89 45 00 49 89 c5 48 8d 9d e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 4c 8b 74 24 28 0f 85 61 01 00 00 8b 1b 31 ff RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000 RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48 RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0 R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000 FS: 00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358 sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248 sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653 sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783 sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212 sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169 sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73 __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579","https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a","https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488","https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de","https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0","https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155","https://git.kernel.org/stable/c/2272e2db38f2e85929278146d7c770f22f528579","https://git.kernel.org/stable/c/4db783d68b9b39a411a96096c10828ff5dfada7a","https://git.kernel.org/stable/c/55f7eb4001ef2a3b48cf039cf263f9ed0ec5a488","https://git.kernel.org/stable/c/9df3b2474a627994433a87cbf325a562555b17de","https://git.kernel.org/stable/c/e31b25cc2066d3f2b6c38579253882008d4469b0","https://git.kernel.org/stable/c/ea0cb87402f774b0e1214ffba0f57028b27cf155"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42259 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) | ["https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60","https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d","https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab","https://git.kernel.org/stable/c/8bdd9ef7e9b1b2a73e394712b72b22055e0e26c3","https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7","https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39","https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b","https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2dd60cf06","https://project-zero.issues.chromium.org/issues/42451707"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43824 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init() Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference. Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747) Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables. [kwilczynski: commit log] | ["https://git.kernel.org/stable/c/5a5095a8bd1bd349cce1c879e5e44407a34dda8a","https://git.kernel.org/stable/c/af4ad016abb1632ff7ee598a6037952b495e5b80"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46739 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind For primary VM Bus channels, primary_channel pointer is always NULL. This pointer is valid only for the secondary channels. Also, rescind callback is meant for primary channels only. Fix NULL pointer dereference by retrieving the device_obj from the parent for the primary channel. | ["https://git.kernel.org/stable/c/1d8e020e51ab07e40f9dd00b52f1da7d96fec04c","https://git.kernel.org/stable/c/2be373469be1774bbe03b0fa7e2854e65005b1cc","https://git.kernel.org/stable/c/3005091cd537ef8cdb7530dcb2ecfba8d2ef475c","https://git.kernel.org/stable/c/3d414b64ecf6fd717d7510ffb893c6f23acbf50e","https://git.kernel.org/stable/c/928e399e84f4e80307dce44e89415115c473275b","https://git.kernel.org/stable/c/de6946be9c8bc7d2279123433495af7c21011b99","https://git.kernel.org/stable/c/f38f46da80a2ab7d1b2f8fcb444c916034a2dac4","https://git.kernel.org/stable/c/fb1adbd7e50f3d2de56d0a2bb0700e2e819a329e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48912 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: fix use-after-free in __nf_register_net_hook() We must not dereference @new_hooks after nf_hook_mutex has been released, because other threads might have freed our allocated hooks already. BUG: KASAN: use-after-free in nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline] BUG: KASAN: use-after-free in hooks_validate net/netfilter/core.c:171 [inline] BUG: KASAN: use-after-free in __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438 Read of size 2 at addr ffff88801c1a8000 by task syz-executor237/4430 CPU: 1 PID: 4430 Comm: syz-executor237 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 nf_hook_entries_get_hook_ops include/linux/netfilter.h:130 [inline] hooks_validate net/netfilter/core.c:171 [inline] __nf_register_net_hook+0x77a/0x820 net/netfilter/core.c:438 nf_register_net_hook+0x114/0x170 net/netfilter/core.c:571 nf_register_net_hooks+0x59/0xc0 net/netfilter/core.c:587 nf_synproxy_ipv6_init+0x85/0xe0 net/netfilter/nf_synproxy_core.c:1218 synproxy_tg6_check+0x30d/0x560 net/ipv6/netfilter/ip6t_SYNPROXY.c:81 xt_check_target+0x26c/0x9e0 net/netfilter/x_tables.c:1038 check_target net/ipv6/netfilter/ip6_tables.c:530 [inline] find_check_entry.constprop.0+0x7f1/0x9e0 net/ipv6/netfilter/ip6_tables.c:573 translate_table+0xc8b/0x1750 net/ipv6/netfilter/ip6_tables.c:735 do_replace net/ipv6/netfilter/ip6_tables.c:1153 [inline] do_ip6t_set_ctl+0x56e/0xb90 net/ipv6/netfilter/ip6_tables.c:1639 nf_setsockopt+0x83/0xe0 net/netfilter/nf_sockopt.c:101 ipv6_setsockopt+0x122/0x180 net/ipv6/ipv6_sockglue.c:1024 rawv6_setsockopt+0xd3/0x6a0 net/ipv6/raw.c:1084 __sys_setsockopt+0x2db/0x610 net/socket.c:2180 __do_sys_setsockopt net/socket.c:2191 [inline] __se_sys_setsockopt net/socket.c:2188 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2188 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f65a1ace7d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 71 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f65a1a7f308 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 00007f65a1ace7d9 RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003 RBP: 00007f65a1b574c8 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000000 R11: 0000000000000246 R12: 00007f65a1b55130 R13: 00007f65a1b574c0 R14: 00007f65a1b24090 R15: 0000000000022000 </TASK> The buggy address belongs to the page: page:ffffea0000706a00 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1c1a8 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000000000 ffffea0001c1b108 ffffea000046dd08 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 2, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 4430, ts 1061781545818, free_ts 1061791488993 prep_new_page mm/page_alloc.c:2434 [inline] get_page_from_freelist+0xa72/0x2f50 mm/page_alloc.c:4165 __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5389 __alloc_pages_node include/linux/gfp.h:572 [inline] alloc_pages_node include/linux/gfp.h:595 [inline] kmalloc_large_node+0x62/0x130 mm/slub.c:4438 __kmalloc_node+0x35a/0x4a0 mm/slub. ---truncated--- | ["https://git.kernel.org/stable/c/05f7927b25d2635e87267ff6c79db79fb46cf313","https://git.kernel.org/stable/c/49c24579cec41e32f13d57b337fd28fb208d4a5b","https://git.kernel.org/stable/c/56763f12b0f02706576a088e85ef856deacc98a0","https://git.kernel.org/stable/c/5a8076e98dde17224dd47283b894a8b1dbe1bc72","https://git.kernel.org/stable/c/8b0142c4143c1ca297dcf2c0cdd045d65dae2344","https://git.kernel.org/stable/c/bd61f192a339b1095dfd6d56073a5265934c2979","https://git.kernel.org/stable/c/bdd8fc1b826e6f23963f5bef3f7431c6188ec954"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42271 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/iucv: fix use after free in iucv_sock_close() iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn(). Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing. Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv. B) Change iucv tasklet into worker and use only lock_sock() in af_iucv. | ["https://git.kernel.org/stable/c/01437282fd3904810603f3dc98d2cac6b8b6fc84","https://git.kernel.org/stable/c/37652fbef9809411cea55ea5fa1a170e299efcd0","https://git.kernel.org/stable/c/69620522c48ce8215e5eb55ffbab8cafee8f407d","https://git.kernel.org/stable/c/84f40b46787ecb67c7ad08a5bb1376141fa10c01","https://git.kernel.org/stable/c/8b424c9e44111c5a76f41c6b741f8d4c4179d876","https://git.kernel.org/stable/c/ac758e1f663fe9bc64f6b47212a2aa18697524f5","https://git.kernel.org/stable/c/c65f72eec60a34ace031426e04e9aff8e5f04895","https://git.kernel.org/stable/c/f558120cd709682b739207b48cf7479fd9568431"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41092 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Fix potential UAF by revoke of fence registers CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1) | ["https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7","https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d","https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc","https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50","https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6","https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535","https://git.kernel.org/stable/c/06dec31a0a5112a91f49085e8a8fa1a82296d5c7","https://git.kernel.org/stable/c/29c0fdf49078ab161570d3d1c6e13d66f182717d","https://git.kernel.org/stable/c/414f4a31f7a811008fd9a33b06216b060bad18fc","https://git.kernel.org/stable/c/996c3412a06578e9d779a16b9e79ace18125ab50","https://git.kernel.org/stable/c/ca0fabd365a27a94a36e68a7a02df8ff3c13dac6","https://git.kernel.org/stable/c/f771b91f21c46ad1217328d05e72a2c7e3add535"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49667 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix use-after-free after 802.3ad slave unbind commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection"), resolve case, when there is several aggregation groups in the same bond. bond_3ad_unbind_slave will invalidate (clear) aggregator when __agg_active_ports return zero. So, ad_clear_agg can be executed even, when num_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for, previously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave will not update slave ports list, because lag_ports==NULL. So, here we got slave ports, pointing to freed aggregator memory. Fix with checking actual number of ports in group (as was before commit 0622cab0341c ("bonding: fix 802.3ad aggregator reselection") ), before ad_clear_agg(). The KASAN logs are as follows: [ 767.617392] ================================================================== [ 767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470 [ 767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767 [ 767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G O 5.15.11 #15 [ 767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler [ 767.666468] Call trace: [ 767.668930] dump_backtrace+0x0/0x2d0 [ 767.672625] show_stack+0x24/0x30 [ 767.675965] dump_stack_lvl+0x68/0x84 [ 767.679659] print_address_description.constprop.0+0x74/0x2b8 [ 767.685451] kasan_report+0x1f0/0x260 [ 767.689148] __asan_load2+0x94/0xd0 [ 767.692667] bond_3ad_state_machine_handler+0x13dc/0x1470 | ["https://git.kernel.org/stable/c/050133e1aa2cb49bb17be847d48a4431598ef562","https://git.kernel.org/stable/c/2765749def4765c5052a4c66445cf4c96fcccdbc","https://git.kernel.org/stable/c/63b2fe509f69b90168a75e04e14573dccf7984e6","https://git.kernel.org/stable/c/893825289ba840afd86bfffcb6f7f363c73efff8","https://git.kernel.org/stable/c/a853b7a3a9fd1d74a4ccdd9cd73512b7dace2f1e","https://git.kernel.org/stable/c/b90ac60303063a43e17dd4aec159067599d255e6","https://git.kernel.org/stable/c/ef0af7d08d26c5333ff4944a559279464edf6f15","https://git.kernel.org/stable/c/f162f7c348fa2a5555bafdb5cc890b89b221e69c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57850 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jffs2: Prevent rtime decompress memory corruption The rtime decompression routine does not fully check bounds during the entirety of the decompression pass and can corrupt memory outside the decompression buffer if the compressed data is corrupted. This adds the required check to prevent this failure mode. | ["https://git.kernel.org/stable/c/421f9e9f0fae9f8e721ffa07f22d9765fa1214d5","https://git.kernel.org/stable/c/47c9a7f81027a78afea9d2e9a54bfd8fabb6b3d0","https://git.kernel.org/stable/c/6808a1812a3419542223e7fe9e2de577e99e45d1","https://git.kernel.org/stable/c/bd384b04ad1995441b18fe6c1366d02de8c5d5eb","https://git.kernel.org/stable/c/dc39b08fcc3831b0bc46add91ba93cd2aab50716","https://git.kernel.org/stable/c/f6fc251baefc3cdc4f41f2f5a47940d7d4a67332","https://git.kernel.org/stable/c/fe051552f5078fa02d593847529a3884305a6ffe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52679 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: of: Fix double free in of_parse_phandle_with_args_map In of_parse_phandle_with_args_map() the inner loop that iterates through the map entries calls of_node_put(new) to free the reference acquired by the previous iteration of the inner loop. This assumes that the value of "new" is NULL on the first iteration of the inner loop. Make sure that this is true in all iterations of the outer loop by setting "new" to NULL after its value is assigned to "cur". Extend the unittest to detect the double free and add an additional test case that actually triggers this path. | ["https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db","https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21","https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b","https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2","https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8","https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd","https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7","https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea","https://git.kernel.org/stable/c/26b4d702c44f9e5cf3c5c001ae619a4a001889db","https://git.kernel.org/stable/c/4541004084527ce9e95a818ebbc4e6b293ffca21","https://git.kernel.org/stable/c/4dde83569832f9377362e50f7748463340c5db6b","https://git.kernel.org/stable/c/a0a061151a6200c13149dbcdb6c065203c8425d2","https://git.kernel.org/stable/c/b64d09a4e8596f76d27f4b4a90a1cf6baf6a82f8","https://git.kernel.org/stable/c/b9d760dae5b10e73369b769073525acd7b3be2bd","https://git.kernel.org/stable/c/cafa992134124e785609a406da4ff2b54052aff7","https://git.kernel.org/stable/c/d5f490343c77e6708b6c4aa7dbbfbcbb9546adea","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26981 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix OOB in nilfs_set_de_type The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is defined as "S_IFMT >> S_SHIFT", but the nilfs_set_de_type() function, which uses this array, specifies the index to read from the array in the same way as "(mode & S_IFMT) >> S_SHIFT". static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode *inode) { umode_t mode = inode->i_mode; de->file_type = nilfs_type_by_mode[(mode & S_IFMT)>>S_SHIFT]; // oob } However, when the index is determined this way, an out-of-bounds (OOB) error occurs by referring to an index that is 1 larger than the array size when the condition "mode & S_IFMT == S_IFMT" is satisfied. Therefore, a patch to resize the nilfs_type_by_mode array should be applied to prevent OOB errors. | ["https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243","https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9","https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1","https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611","https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f","https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8","https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0","https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16","https://git.kernel.org/stable/c/054f29e9ca05be3906544c5f2a2c7321c30a4243","https://git.kernel.org/stable/c/2382eae66b196c31893984a538908c3eb7506ff9","https://git.kernel.org/stable/c/7061c7efbb9e8f11ce92d6b4646405ea2b0b4de1","https://git.kernel.org/stable/c/897ac5306bbeb83e90c437326f7044c79a17c611","https://git.kernel.org/stable/c/90823f8d9ecca3d5fa6b102c8e464c62f416975f","https://git.kernel.org/stable/c/90f43980ea6be4ad903e389be9a27a2a0018f1c8","https://git.kernel.org/stable/c/bdbe483da21f852c93b22557b146bc4d989260f0","https://git.kernel.org/stable/c/c4a7dc9523b59b3e73fd522c73e95e072f876b16","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36940 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: core: delete incorrect free in pinctrl_enable() The "pctldev" struct is allocated in devm_pinctrl_register_and_init(). It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(), so freeing it in pinctrl_enable() will lead to a double free. The devm_pinctrl_dev_release() function frees the pindescs and destroys the mutex as well. | ["https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068","https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca","https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79","https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c","https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d","https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e","https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd","https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba","https://git.kernel.org/stable/c/288bc4aa75f150d6f1ee82dd43c6da1b438b6068","https://git.kernel.org/stable/c/41f88ef8ba387a12f4a2b8c400b6c9e8e54b2cca","https://git.kernel.org/stable/c/5038a66dad0199de60e5671603ea6623eb9e5c79","https://git.kernel.org/stable/c/558c8039fdf596a584a92c171cbf3298919c448c","https://git.kernel.org/stable/c/735f4c6b6771eafe336404c157ca683ad72a040d","https://git.kernel.org/stable/c/ac7d65795827dc0cf7662384ed27caf4066bd72e","https://git.kernel.org/stable/c/cdaa171473d98962ae86f2a663d398fda2fbeefd","https://git.kernel.org/stable/c/f9f1e321d53e4c5b666b66e5b43da29841fb55ba","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38583 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix use-after-free of timer for log writer thread Patch series "nilfs2: fix log writer related issues". This bug fix series covers three nilfs2 log writer-related issues, including a timer use-after-free issue and potential deadlock issue on unmount, and a potential freeze issue in event synchronization found during their analysis. Details are described in each commit log. This patch (of 3): A use-after-free issue has been reported regarding the timer sc_timer on the nilfs_sc_info structure. The problem is that even though it is used to wake up a sleeping log writer thread, sc_timer is not shut down until the nilfs_sc_info structure is about to be freed, and is used regardless of the thread's lifetime. Fix this issue by limiting the use of sc_timer only while the log writer thread is alive. | ["https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6","https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148","https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb","https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d","https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164","https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a","https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438","https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7","https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0","https://git.kernel.org/stable/c/2f12b2c03c5dae1a0de0a9e5853177e3d6eee3c6","https://git.kernel.org/stable/c/67fa90d4a2ccd9ebb0e1e168c7d0b5d0cf3c7148","https://git.kernel.org/stable/c/68e738be5c518fc3c4e9146b66f67c8fee0135fb","https://git.kernel.org/stable/c/822ae5a8eac30478578a75f7e064f0584931bf2d","https://git.kernel.org/stable/c/82933c84f188dcfe89eb26b0b48ab5d1ca99d164","https://git.kernel.org/stable/c/86a30d6302deddb9fb97ba6fc4b04d0e870b582a","https://git.kernel.org/stable/c/e65ccf3a4de4f0c763d94789615b83e11f204438","https://git.kernel.org/stable/c/f5d4e04634c9cf68bdf23de08ada0bb92e8befe7","https://git.kernel.org/stable/c/f9186bba4ea282b07293c1c892441df3a5441cb0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1670 | High | fixed |
|
A flaw use after free in the Linux kernel Xircom 16-bit PCMCIA (PC-card) Ethernet driver was found.A local user could use this flaw to crash the system or potentially escalate their privileges on the system. | ["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230316161526.1568982-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230526-0010/","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230316161526.1568982-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230526-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42280 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix a use after free in hfcmulti_tx() Don't dereference *sp after calling dev_kfree_skb(*sp). | ["https://git.kernel.org/stable/c/4d8b642985ae24f4b3656438eb8489834a17bb80","https://git.kernel.org/stable/c/61ab751451f5ebd0b98e02276a44e23a10110402","https://git.kernel.org/stable/c/70db2c84631f50e02e6b32b543700699dd395803","https://git.kernel.org/stable/c/7e4a539bca7d8d20f2c5d93c18cce8ef77cd78e0","https://git.kernel.org/stable/c/8f4030277dfb9dbe04fd78566b19931097c9d629","https://git.kernel.org/stable/c/9460ac3dd1ae033bc2b021a458fb535a0c36ddb2","https://git.kernel.org/stable/c/d3e4d4a98c5629ccdcb762a0ff6c82ba9738a0c3","https://git.kernel.org/stable/c/ddc79556641ee070d36be0de4a1f0a16a71f1fc7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42285 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix a use-after-free related to destroying CM IDs iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler; rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished. | ["https://git.kernel.org/stable/c/557d035fe88d78dd51664f4dc0e1896c04c97cf6","https://git.kernel.org/stable/c/7f25f296fc9bd0435be14e89bf657cd615a23574","https://git.kernel.org/stable/c/94ee7ff99b87435ec63211f632918dc7f44dac79","https://git.kernel.org/stable/c/aee2424246f9f1dadc33faa78990c1e2eb7826e4","https://git.kernel.org/stable/c/d91d253c87fd1efece521ff2612078a35af673c6","https://git.kernel.org/stable/c/dc8074b8901caabb97c2d353abd6b4e7fa5a59a5","https://git.kernel.org/stable/c/ee39384ee787e86e9db4efb843818ef0ea9cb8ae","https://git.kernel.org/stable/c/ff5bbbdee08287d75d72e65b72a2b76d9637892a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44985 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible UAF in ip6_xmit() If skb_expand_head() returns NULL, skb has been freed and the associated dst/idev could also have been freed. We must use rcu_read_lock() to prevent a possible UAF. | ["https://git.kernel.org/stable/c/124b428fe28064c809e4237b0b38e97200a8a4a8","https://git.kernel.org/stable/c/2d5ff7e339d04622d8282661df36151906d0e1c7","https://git.kernel.org/stable/c/38a21c026ed2cc7232414cb166efc1923f34af17","https://git.kernel.org/stable/c/975f764e96f71616b530e300c1bb2ac0ce0c2596","https://git.kernel.org/stable/c/b3a3d5333c13a1be57499581eab4a8fc94d57f36","https://git.kernel.org/stable/c/c47e022011719fc5727bca661d662303180535ba","https://git.kernel.org/stable/c/fc88d6c1f2895a5775795d82ec581afdff7661d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44987 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent UAF in ip6_send_skb() syzbot reported an UAF in ip6_send_skb() [1] After ip6_local_out() has returned, we no longer can safely dereference rt, unless we hold rcu_read_lock(). A similar issue has been fixed in commit a688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()") Another potential issue in ip6_finish_output2() is handled in a separate patch. [1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530 CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f936bf79e79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 </TASK> Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree. ---truncated--- | ["https://git.kernel.org/stable/c/24e93695b1239fbe4c31e224372be77f82dab69a","https://git.kernel.org/stable/c/571567e0277008459750f0728f246086b2659429","https://git.kernel.org/stable/c/9a3e55afa95ed4ac9eda112d4f918af645d72f25","https://git.kernel.org/stable/c/af1dde074ee2ed7dd5bdca4e7e8ba17f44e7b011","https://git.kernel.org/stable/c/cb5880a0de12c7f618d2bdd84e2d985f1e06ed7e","https://git.kernel.org/stable/c/ce2f6cfab2c637d0bd9762104023a15d0ab7c0a8","https://git.kernel.org/stable/c/e44bd76dd072756e674f45c5be00153f4ded68b2","https://git.kernel.org/stable/c/faa389b2fbaaec7fd27a390b4896139f9da662e3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35867 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_stats_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65","https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49","https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7","https://git.kernel.org/stable/c/838ec01ea8d3deb5d123e8ed9022e8162dc3f503","https://git.kernel.org/stable/c/bb6570085826291dc392005f9fec16ea5da3c8ad","https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39","http://www.openwall.com/lists/oss-security/2024/05/29/2","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/0865ffefea197b437ba78b5dd8d8e256253efd65","https://git.kernel.org/stable/c/16b7d785775eb03929766819415055e367398f49","https://git.kernel.org/stable/c/1e12f0d5c66f07c934041621351973a116fa13c7","https://git.kernel.org/stable/c/c3cf8b74c57924c0985e49a1fdf02d3395111f39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41000 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block/ioctl: prefer different overflow check Running syzkaller with the newly reintroduced signed integer overflow sanitizer shows this report: [ 62.982337] ------------[ cut here ]------------ [ 62.985692] cgroup: Invalid name [ 62.986211] UBSAN: signed-integer-overflow in ../block/ioctl.c:36:46 [ 62.989370] 9pnet_fd: p9_fd_create_tcp (7343): problem connecting socket to 127.0.0.1 [ 62.992992] 9223372036854775807 + 4095 cannot be represented in type 'long long' [ 62.997827] 9pnet_fd: p9_fd_create_tcp (7345): problem connecting socket to 127.0.0.1 [ 62.999369] random: crng reseeded on system resumption [ 63.000634] GUP no longer grows the stack in syz-executor.2 (7353): 20002000-20003000 (20001000) [ 63.000668] CPU: 0 PID: 7353 Comm: syz-executor.2 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 63.000677] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 63.000682] Call Trace: [ 63.000686] <TASK> [ 63.000731] dump_stack_lvl+0x93/0xd0 [ 63.000919] __get_user_pages+0x903/0xd30 [ 63.001030] __gup_longterm_locked+0x153e/0x1ba0 [ 63.001041] ? _raw_read_unlock_irqrestore+0x17/0x50 [ 63.001072] ? try_get_folio+0x29c/0x2d0 [ 63.001083] internal_get_user_pages_fast+0x1119/0x1530 [ 63.001109] iov_iter_extract_pages+0x23b/0x580 [ 63.001206] bio_iov_iter_get_pages+0x4de/0x1220 [ 63.001235] iomap_dio_bio_iter+0x9b6/0x1410 [ 63.001297] __iomap_dio_rw+0xab4/0x1810 [ 63.001316] iomap_dio_rw+0x45/0xa0 [ 63.001328] ext4_file_write_iter+0xdde/0x1390 [ 63.001372] vfs_write+0x599/0xbd0 [ 63.001394] ksys_write+0xc8/0x190 [ 63.001403] do_syscall_64+0xd4/0x1b0 [ 63.001421] ? arch_exit_to_user_mode_prepare+0x3a/0x60 [ 63.001479] entry_SYSCALL_64_after_hwframe+0x6f/0x77 [ 63.001535] RIP: 0033:0x7f7fd3ebf539 [ 63.001551] Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 [ 63.001562] RSP: 002b:00007f7fd32570c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 63.001584] RAX: ffffffffffffffda RBX: 00007f7fd3ff3f80 RCX: 00007f7fd3ebf539 [ 63.001590] RDX: 4db6d1e4f7e43360 RSI: 0000000020000000 RDI: 0000000000000004 [ 63.001595] RBP: 00007f7fd3f1e496 R08: 0000000000000000 R09: 0000000000000000 [ 63.001599] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 63.001604] R13: 0000000000000006 R14: 00007f7fd3ff3f80 R15: 00007ffd415ad2b8 ... [ 63.018142] ---[ end trace ]--- Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang; It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rework this overflow checking logic to not actually perform an overflow during the check itself, thus avoiding the UBSAN splat. [1]: https://github.com/llvm/llvm-project/pull/82432 | ["https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66","https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e","https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24","https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9","https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9","https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e","https://git.kernel.org/stable/c/3220c90f4dbdc6d20d0608b164d964434a810d66","https://git.kernel.org/stable/c/54160fb1db2de367485f21e30196c42f7ee0be4e","https://git.kernel.org/stable/c/58706e482bf45c4db48b0c53aba2468c97adda24","https://git.kernel.org/stable/c/61ec76ec930709b7bcd69029ef1fe90491f20cf9","https://git.kernel.org/stable/c/ccb326b5f9e623eb7f130fbbf2505ec0e2dcaff9","https://git.kernel.org/stable/c/fd841ee01fb4a79cb7f5cc424b5c96c3a73b2d1e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39487 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set() In function bond_option_arp_ip_targets_set(), if newval->string is an empty string, newval->string+1 will point to the byte after the string, causing an out-of-bound read. BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418 Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107 CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910 drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace ]--- Fix it by adding a check of string length before using it. | ["https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e","https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1","https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b","https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da","https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8","https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9","https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f","https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d","https://git.kernel.org/stable/c/6a8a4fd082c439e19fede027e80c79bc4c84bb8e","https://git.kernel.org/stable/c/6b21346b399fd1336fe59233a17eb5ce73041ee1","https://git.kernel.org/stable/c/707c85ba3527ad6aa25552033576b0f1ff835d7b","https://git.kernel.org/stable/c/9f835e48bd4c75fdf6a9cff3f0b806a7abde78da","https://git.kernel.org/stable/c/b75e33eae8667084bd4a63e67657c6a5a0f8d1e8","https://git.kernel.org/stable/c/bfd14e5915c2669f292a31d028e75dcd82f1e7e9","https://git.kernel.org/stable/c/c8eb8ab9a44ff0e73492d0a12a643c449f641a9f","https://git.kernel.org/stable/c/e271ff53807e8f2c628758290f0e499dbe51cb3d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0330 | High | fixed |
|
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system. | ["http://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2042404","https://security.netapp.com/advisory/ntap-20220526-0001/","https://www.openwall.com/lists/oss-security/2022/01/25/12","http://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2042404","https://security.netapp.com/advisory/ntap-20220526-0001/","https://www.openwall.com/lists/oss-security/2022/01/25/12"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-34027 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock to avoid racing with checkpoint, otherwise, filesystem metadata including blkaddr in dnode, inode fields and .total_valid_block_count may be corrupted after SPO case. | ["https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019","https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b","https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f","https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4","https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b","https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182","https://git.kernel.org/stable/c/0a4ed2d97cb6d044196cc3e726b6699222b41019","https://git.kernel.org/stable/c/329edb7c9e3b6ca27e6ca67ab1cdda1740fb3a2b","https://git.kernel.org/stable/c/5d47d63883735718825ca2efc4fca6915469774f","https://git.kernel.org/stable/c/69136304fd144144a4828c7b7b149d0f80321ba4","https://git.kernel.org/stable/c/a6e1f7744e9b84f86a629a76024bba8468aa153b","https://git.kernel.org/stable/c/b5bac43875aa27ec032dbbb86173baae6dce6182"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41040 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix UAF when resolving a clash KASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: <IRQ> dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 </IRQ> <TASK> asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 The ct may be dropped if a clash has been resolved but is still passed to the tcf_ct_flow_table_process_conn function for further usage. This issue can be fixed by retrieving ct from skb again after confirming conntrack. | ["https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3","https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f","https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae","https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932","https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55","https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e","https://git.kernel.org/stable/c/26488172b0292bed837b95a006a3f3431d1898c3","https://git.kernel.org/stable/c/2b4d68df3f57ea746c430941ba9c03d7d8b5a23f","https://git.kernel.org/stable/c/4e71b10a100861fb27d9c5755dfd68f615629fae","https://git.kernel.org/stable/c/799a34901b634008db4a7ece3900e2b971d4c932","https://git.kernel.org/stable/c/b81a523d54ea689414f67c9fb81a5b917a41ed55","https://git.kernel.org/stable/c/ef472cc6693b16b202a916482df72f35d94bd69e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48674 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: erofs: fix pcluster use-after-free on UP platforms During stress testing with CONFIG_SMP disabled, KASAN reports as below: ================================================================== BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30 Read of size 8 at addr ffff8881094223f8 by task stress/7789 CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 Call Trace: <TASK> .. __mutex_lock+0xe5/0xc30 .. z_erofs_do_read_page+0x8ce/0x1560 .. z_erofs_readahead+0x31c/0x580 .. Freed by task 7787 kasan_save_stack+0x1e/0x40 kasan_set_track+0x20/0x30 kasan_set_free_info+0x20/0x40 __kasan_slab_free+0x10c/0x190 kmem_cache_free+0xed/0x380 rcu_core+0x3d5/0xc90 __do_softirq+0x12d/0x389 Last potentially related work creation: kasan_save_stack+0x1e/0x40 __kasan_record_aux_stack+0x97/0xb0 call_rcu+0x3d/0x3f0 erofs_shrink_workstation+0x11f/0x210 erofs_shrink_scan+0xdc/0x170 shrink_slab.constprop.0+0x296/0x530 drop_slab+0x1c/0x70 drop_caches_sysctl_handler+0x70/0x80 proc_sys_call_handler+0x20a/0x2f0 vfs_write+0x555/0x6c0 ksys_write+0xbe/0x160 do_syscall_64+0x3b/0x90 The root cause is that erofs_workgroup_unfreeze() doesn't reset to orig_val thus it causes a race that the pcluster reuses unexpectedly before freeing. Since UP platforms are quite rare now, such path becomes unnecessary. Let's drop such specific-designed path directly instead. | ["https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315","https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556","https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e","https://git.kernel.org/stable/c/2f44013e39984c127c6efedf70e6b5f4e9dcf315","https://git.kernel.org/stable/c/8ddd001cef5e82d19192e6861068463ecca5f556","https://git.kernel.org/stable/c/94c34faaafe7b55adc2d8d881db195b646959b9e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48988 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memcg: fix possible use-after-free in memcg_write_event_control() memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. | ["https://git.kernel.org/stable/c/0ed074317b835caa6c03bcfa8f133365324673dc","https://git.kernel.org/stable/c/35963b31821920908e397146502066f6b032c917","https://git.kernel.org/stable/c/4a7ba45b1a435e7097ca0f79a847d0949d0eb088","https://git.kernel.org/stable/c/aad8bbd17a1d586005feb9226c2e9cfce1432e13","https://git.kernel.org/stable/c/b77600e26fd48727a95ffd50ba1e937efb548125","https://git.kernel.org/stable/c/e1ae97624ecf400ea56c238bff23e5cd139df0b8","https://git.kernel.org/stable/c/f1f7f36cf682fa59db15e2089039a2eeb58ff2ad"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27013 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f | ["https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421","https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad","https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3","https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa","https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713","https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588","https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb","https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540","https://git.kernel.org/stable/c/14cdb43dbc827e18ac7d5b30c5b4c676219f1421","https://git.kernel.org/stable/c/40f4ced305c6c47487d3cd8da54676e2acc1a6ad","https://git.kernel.org/stable/c/4b0dcae5c4797bf31c63011ed62917210d3fdac3","https://git.kernel.org/stable/c/52854101180beccdb9dc2077a3bea31b6ad48dfa","https://git.kernel.org/stable/c/62e27ef18eb4f0d33bbae8e9ef56b99696a74713","https://git.kernel.org/stable/c/68459b8e3ee554ce71878af9eb69659b9462c588","https://git.kernel.org/stable/c/a50dbeca28acf7051dfa92786b85f704c75db6eb","https://git.kernel.org/stable/c/f8bbc07ac535593139c875ffa19af924b1084540","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36941 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: don't free NULL coalescing rule If the parsing fails, we can dereference a NULL pointer here. | ["https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d","https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a","https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307","https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7","https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457","https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4","https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f","https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383","https://git.kernel.org/stable/c/244822c09b4f9aedfb5977f03c0deeb39da8ec7d","https://git.kernel.org/stable/c/327382dc0f16b268950b96e0052595efd80f7b0a","https://git.kernel.org/stable/c/5a730a161ac2290d46d49be76b2b1aee8d2eb307","https://git.kernel.org/stable/c/801ea33ae82d6a9d954074fbcf8ea9d18f1543a7","https://git.kernel.org/stable/c/97792d0611ae2e6fe3ccefb0a94a1d802317c457","https://git.kernel.org/stable/c/ad12c74e953b68ad85c78adc6408ed8435c64af4","https://git.kernel.org/stable/c/b0db4caa10f2e4e811cf88744fbf0d074b67ec1f","https://git.kernel.org/stable/c/f92772a642485394db5c9a17bd0ee73fc6902383","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36954 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: fix a possible memleak in tipc_buf_append __skb_linearize() doesn't free the skb when it fails, so move '*buf = NULL' after __skb_linearize(), so that the skb can be freed on the err path. | ["https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6","https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae","https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565","https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c","https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574","https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d","https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd","https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e","https://git.kernel.org/stable/c/01cd1b7b685751ee422d00d050292a3d277652d6","https://git.kernel.org/stable/c/2f87fd9476cf9725d774e6dcb7d17859c6a6d1ae","https://git.kernel.org/stable/c/3210d34fda4caff212cb53729e6bd46de604d565","https://git.kernel.org/stable/c/42c8471b0566c7539e7dd584b4d0ebd3cec8cb2c","https://git.kernel.org/stable/c/614c5a5ae45a921595952117b2e2bd4d4bf9b574","https://git.kernel.org/stable/c/97bf6f81b29a8efaf5d0983251a7450e5794370d","https://git.kernel.org/stable/c/adbce6d20da6254c86425a8d4359b221b5ccbccd","https://git.kernel.org/stable/c/d03a82f4f8144befdc10518e732e2a60b34c870e","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38549 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Add 0 size check to mtk_drm_gem_obj Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer. Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL. | ["https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4","https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05","https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0","https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364","https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7","https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594","https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67","https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350","https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405","https://git.kernel.org/stable/c/0e3b6f9123726858cac299e1654e3d20424cabe4","https://git.kernel.org/stable/c/13562c2d48c9ee330de1077d00146742be368f05","https://git.kernel.org/stable/c/1e4350095e8ab2577ee05f8c3b044e661b5af9a0","https://git.kernel.org/stable/c/79078880795478d551a05acc41f957700030d364","https://git.kernel.org/stable/c/9489951e3ae505534c4013db4e76b1b5a3151ac7","https://git.kernel.org/stable/c/af26ea99019caee1500bf7e60c861136c0bf8594","https://git.kernel.org/stable/c/be34a1b351ea7faeb15dde8c44fe89de3980ae67","https://git.kernel.org/stable/c/d17b75ee9c2e44d3a3682c4ea5ab713ea6073350","https://git.kernel.org/stable/c/fb4aabdb1b48c25d9e1ee28f89440fd2ce556405"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42244 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ] | ["https://git.kernel.org/stable/c/1094ed500987e67a9d18b0f95e1812f1cc720856","https://git.kernel.org/stable/c/553e67dec846323b5575e78a776cf594c13f98c4","https://git.kernel.org/stable/c/5ae6a64f18211851c8df6b4221381c438b9a7348","https://git.kernel.org/stable/c/932a86a711c722b45ed47ba2103adca34d225b33","https://git.kernel.org/stable/c/b14aa5673e0a8077ff4b74f0bb260735e7d5e6a4","https://git.kernel.org/stable/c/c15a688e49987385baa8804bf65d570e362f8576"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52889 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: apparmor: Fix null pointer deref when receiving skb during sock creation The panic below is observed when receiving ICMP packets with secmark set while an ICMP raw socket is being created. SK_CTX(sk)->label is updated in apparmor_socket_post_create(), but the packet is delivered to the socket before that, causing the null pointer dereference. Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: <IRQ> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 </IRQ> <TASK> asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc | ["https://git.kernel.org/stable/c/0abe35bc48d4ec80424b1f4b3560c0e082cbd5c1","https://git.kernel.org/stable/c/290a6b88e8c19b6636ed1acc733d1458206f7697","https://git.kernel.org/stable/c/347dcb84a4874b5fb375092c08d8cc4069b94f81","https://git.kernel.org/stable/c/46c17ead5b7389e22e7dc9903fd0ba865d05bda2","https://git.kernel.org/stable/c/6c920754f62cefc63fccdc38a062c7c3452e2961","https://git.kernel.org/stable/c/ead2ad1d9f045f26fdce3ef1644913b3a6cd38f2","https://git.kernel.org/stable/c/fce09ea314505a52f2436397608fa0a5d0934fb1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42283 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Initialize all fields in dumped nexthops struct nexthop_grp contains two reserved fields that are not initialized by nla_put_nh_group(), and carry garbage. This can be observed e.g. with strace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52 The fields are reserved and therefore not currently used. But as they are, they leak kernel memory, and the fact they are not just zero complicates repurposing of the fields for new ends. Initialize the full structure. | ["https://git.kernel.org/stable/c/1377de719652d868f5317ba8398b7e74c5f0430b","https://git.kernel.org/stable/c/5cc4d71dda2dd4f1520f40e634a527022e48ccd8","https://git.kernel.org/stable/c/6d745cd0e9720282cd291d36b9db528aea18add2","https://git.kernel.org/stable/c/7704460acd7f5d35eb07c52500987dc9b95313fb","https://git.kernel.org/stable/c/9e8f558a3afe99ce51a642ce0d3637ddc2b5d5d0","https://git.kernel.org/stable/c/a13d3864b76ac87085ec530b2ff8e37482a63a96","https://git.kernel.org/stable/c/fd06cb4a5fc7bda3dea31712618a62af72a1c6cb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43835 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: virtio_net: Fix napi_skb_cache_put warning After the commit bdacf3e34945 ("net: Use nested-BH locking for napi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10 The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case. To resolve this, modify virtnet_poll_tx() to only set NAPI when budget is available. Same for virtnet_poll_cleantx(), which always assumed that it was in a NAPI context. | ["https://git.kernel.org/stable/c/19ac6f29bf64304ef04630c8ab56ecd2059d7aa1","https://git.kernel.org/stable/c/468a729b78895893d0e580ceea49bed8ada2a2bd","https://git.kernel.org/stable/c/6b5325f2457521bbece29499970c0117a648c620","https://git.kernel.org/stable/c/842a97b5e44f0c8a9fc356fe976e0e13ddcf7783","https://git.kernel.org/stable/c/cc7340f18e45886121c131227985d64ef666012f","https://git.kernel.org/stable/c/d3af435e8ace119e58d8e21d3d2d6a4e7c4a4baa","https://git.kernel.org/stable/c/f5e9a22d19bb98a7e86034db85eb295e94187caa","https://git.kernel.org/stable/c/f8321fa75102246d7415a6af441872f6637c93ab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: usb: qmi_wwan: fix memory leak for not ip packets Free the unused skb when not ip packets arrive. | ["https://git.kernel.org/stable/c/37c093449704017870604994ba9b813cdb9475a4","https://git.kernel.org/stable/c/3c90a69533b5bba73401ef884d033ea49ee99662","https://git.kernel.org/stable/c/7ab107544b777c3bd7feb9fe447367d8edd5b202","https://git.kernel.org/stable/c/c4251a3deccad852b27e60625f31fba6cc14372f","https://git.kernel.org/stable/c/c6c5b91424fafc0f83852d961c10c7e43a001882","https://git.kernel.org/stable/c/da518cc9b64df391795d9952aed551e0f782e446","https://git.kernel.org/stable/c/e87f52225e04a7001bf55bbd7a330fa4252327b5","https://git.kernel.org/stable/c/f2c353227de14b0289298ffc3ba92058c4768384"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43871 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: devres: Fix memory leakage caused by driver API devm_free_percpu() It will cause memory leakage when use driver API devm_free_percpu() to free memory allocated by devm_alloc_percpu(), fixed by using devres_release() instead of devres_destroy() within devm_free_percpu(). | ["https://git.kernel.org/stable/c/3047f99caec240a88ccd06197af2868da1af6a96","https://git.kernel.org/stable/c/3dcd0673e47664bc6c719ad47dadac6d55d5950d","https://git.kernel.org/stable/c/700e8abd65b10792b2f179ce4e858f2ca2880f85","https://git.kernel.org/stable/c/95065edb8ebb27771d5f1e898eef6ab43dc6c87c","https://git.kernel.org/stable/c/b044588a16a978cd891cb3d665dd7ae06850d5bf","https://git.kernel.org/stable/c/b67552d7c61f52f1271031adfa7834545ae99701","https://git.kernel.org/stable/c/bd50a974097bb82d52a458bd3ee39fb723129a0c","https://git.kernel.org/stable/c/ef56dcdca8f2a53abc3a83d388b8336447533d85"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43889 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: padata: Fix possible divide-by-0 panic in padata_mt_helper() We are hit with a not easily reproducible divide-by-0 panic in padata.c at bootup time. [ 10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI [ 10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1 [ 10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021 [ 10.017908] Workqueue: events_unbound padata_mt_helper [ 10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0 : [ 10.017963] Call Trace: [ 10.017968] <TASK> [ 10.018004] ? padata_mt_helper+0x39/0xb0 [ 10.018084] process_one_work+0x174/0x330 [ 10.018093] worker_thread+0x266/0x3a0 [ 10.018111] kthread+0xcf/0x100 [ 10.018124] ret_from_fork+0x31/0x50 [ 10.018138] ret_from_fork_asm+0x1a/0x30 [ 10.018147] </TASK> Looking at the padata_mt_helper() function, the only way a divide-by-0 panic can happen is when ps->chunk_size is 0. The way that chunk_size is initialized in padata_do_multithreaded(), chunk_size can be 0 when the min_chunk in the passed-in padata_mt_job structure is 0. Fix this divide-by-0 panic by making sure that chunk_size will be at least 1 no matter what the input parameters are. | ["https://git.kernel.org/stable/c/6d45e1c948a8b7ed6ceddb14319af69424db730c","https://git.kernel.org/stable/c/8f5ffd2af7274853ff91d6cd62541191d9fbd10d","https://git.kernel.org/stable/c/924f788c906dccaca30acab86c7124371e1d6f2c","https://git.kernel.org/stable/c/a29cfcb848c31f22b4de6a531c3e1d68c9bfe09f","https://git.kernel.org/stable/c/ab8b397d5997d8c37610252528edc54bebf9f6d3","https://git.kernel.org/stable/c/da0ffe84fcc1627a7dff82c80b823b94236af905"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43890 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix overflow in get_free_elt() "tracing_map->next_elt" in get_free_elt() is at risk of overflowing. Once it overflows, new elements can still be inserted into the tracing_map even though the maximum number of elements (`max_elts`) has been reached. Continuing to insert elements after the overflow could result in the tracing_map containing "tracing_map->max_size" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using `__tracing_map_insert()`, it will cause an infinite loop with preemption disabled, leading to a CPU hang problem. Fix this by preventing any further increments to "tracing_map->next_elt" once it reaches "tracing_map->max_elt". | ["https://git.kernel.org/stable/c/236bb4690773ab6869b40bedc7bc8d889e36f9d6","https://git.kernel.org/stable/c/302ceb625d7b990db205a15e371f9a71238de91c","https://git.kernel.org/stable/c/788ea62499b3c18541fd6d621964d8fafbc4aec5","https://git.kernel.org/stable/c/a172c7b22bc2feaf489cfc6d6865f7237134fdf8","https://git.kernel.org/stable/c/bcf86c01ca4676316557dd482c8416ece8c2e143","https://git.kernel.org/stable/c/cd10d186a5409a1fe6e976df82858e9773a698da","https://git.kernel.org/stable/c/d3e4dbc2858fe85d1dbd2e72a9fc5dea988b5c18","https://git.kernel.org/stable/c/eb223bf01e688dfe37e813c8988ee11c8c9f8d0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44935 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: Fix null-ptr-deref in reuseport_add_sock(). syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb in reuseport_add_sock(). [0] The repro first creates a listener with SO_REUSEPORT. Then, it creates another listener on the same port and concurrently closes the first listener. The second listen() calls reuseport_add_sock() with the first listener as sk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently, but the close() does clear it by reuseport_detach_sock(). The problem is SCTP does not properly synchronise reuseport_alloc(), reuseport_add_sock(), and reuseport_detach_sock(). The caller of reuseport_alloc() and reuseport_{add,detach}_sock() must provide synchronisation for sockets that are classified into the same reuseport group. Otherwise, such sockets form multiple identical reuseport groups, and all groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packets Also, the reported null-ptr-deref could occur. TCP/UDP guarantees that would not happen by holding the hash bucket lock. Let's apply the locking strategy to __sctp_hash_endpoint() and __sctp_unhash_endpoint(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350 Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14 RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012 RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385 R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0 R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f24e46039b9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032 RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9 RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004 RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0 R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42c R13: ---truncated--- | ["https://git.kernel.org/stable/c/05e4a0fa248240efd99a539853e844f0f0a9e6a5","https://git.kernel.org/stable/c/1407be30fc17eff918a98e0a990c0e988f11dc84","https://git.kernel.org/stable/c/52319d9d2f522ed939af31af70f8c3a0f0f67e6c","https://git.kernel.org/stable/c/54b303d8f9702b8ab618c5032fae886b16356928","https://git.kernel.org/stable/c/9ab0faa7f9ffe31296dbb9bbe6f76c72c14eea18","https://git.kernel.org/stable/c/c9b3fc4f157867e858734e31022ebee8a24f0de7","https://git.kernel.org/stable/c/e809a84c802377ef61525a298a1ec1728759b913"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44965 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/mm: Fix pti_clone_pgtable() alignment assumption Guenter reported dodgy crashes on an i386-nosmp build using GCC-11 that had the form of endless traps until entry stack exhaust and then #DF from the stack guard. It turned out that pti_clone_pgtable() had alignment assumptions on the start address, notably it hard assumes start is PMD aligned. This is true on x86_64, but very much not true on i386. These assumptions can cause the end condition to malfunction, leading to a 'short' clone. Guess what happens when the user mapping has a short copy of the entry text? Use the correct increment form for addr to avoid alignment assumptions. | ["https://git.kernel.org/stable/c/18da1b27ce16a14a9b636af9232acb4fb24f4c9e","https://git.kernel.org/stable/c/25a727233a40a9b33370eec9f0cad67d8fd312f8","https://git.kernel.org/stable/c/41e71dbb0e0a0fe214545fe64af031303a08524c","https://git.kernel.org/stable/c/4d143ae782009b43b4f366402e5c37f59d4e4346","https://git.kernel.org/stable/c/5c580c1050bcbc15c3e78090859d798dcf8c9763","https://git.kernel.org/stable/c/ca07aab70dd3b5e7fddb62d7a6ecd7a7d6d0b2ed","https://git.kernel.org/stable/c/d00c9b4bbc442d99e1dafbdfdab848bc1ead73f6","https://git.kernel.org/stable/c/df3eecb5496f87263d171b254ca6e2758ab3c35c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44971 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register() bcm_sf2_mdio_register() calls of_phy_find_device() and then phy_device_remove() in a loop to remove existing PHY devices. of_phy_find_device() eventually calls bus_find_device(), which calls get_device() on the returned struct device * to increment the refcount. The current implementation does not decrement the refcount, which causes memory leak. This commit adds the missing phy_device_free() call to decrement the refcount via put_device() to balance the refcount. | ["https://git.kernel.org/stable/c/7feef10768ea71d468d9bbc1e0d14c461876768c","https://git.kernel.org/stable/c/a7d2808d67570e6acae45c2a96e0d59986888e4c","https://git.kernel.org/stable/c/b7b8d9f5e679af60c94251fd6728dde34be69a71","https://git.kernel.org/stable/c/c05516c072903f6fb9134b8e7e1ad4bffcdc4819","https://git.kernel.org/stable/c/e3862093ee93fcfbdadcb7957f5f8974fffa806a","https://git.kernel.org/stable/c/f3d5efe18a11f94150fee8b3fda9d62079af640a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44989 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bonding: fix xfrm real_dev null pointer dereference We shouldn't set real_dev to NULL because packets can be in transit and xfrm might call xdo_dev_offload_ok() in parallel. All callbacks assume real_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: <TASK> kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80 | ["https://git.kernel.org/stable/c/21816b696c172c19d53a30d45ee005cce246ed21","https://git.kernel.org/stable/c/2f72c6a66bcd7e0187ec085237fee5db27145294","https://git.kernel.org/stable/c/4582d4ff413a07d4ed8a4823c652dc5207760548","https://git.kernel.org/stable/c/7fa9243391ad2afe798ef4ea2e2851947b95754f","https://git.kernel.org/stable/c/89fc1dca79db5c3e7a2d589ecbf8a3661c65f436","https://git.kernel.org/stable/c/f8cde9805981c50d0c029063dc7d82821806fc44"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44990 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bonding: fix null pointer deref in bond_ipsec_offload_ok We must check if there is an active slave before dereferencing the pointer. | ["https://git.kernel.org/stable/c/0707260a18312bbcd2a5668584e3692d0a29e3f6","https://git.kernel.org/stable/c/2f5bdd68c1ce64bda6bef4d361a3de23b04ccd59","https://git.kernel.org/stable/c/32a0173600c63aadaf2103bf02f074982e8602ab","https://git.kernel.org/stable/c/81216b9352be43f8958092d379f6dec85443c309","https://git.kernel.org/stable/c/95c90e4ad89d493a7a14fa200082e466e2548f9d","https://git.kernel.org/stable/c/b70b0ddfed31fc92c8dc722d0afafc8e14cb550c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45006 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference. Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usb_ep0_reinit() in this case, which ends up calling xhci_configure_endpoint(). On Panther point xHC the xhci_configure_endpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware If xHC address device command fails then a new xhci_virt_device structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usb_ep0_reinit() is called and xhci_configure_endpoint() tries to check and reserve bandwidth [46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: error_code(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usb_hub_wq hub_event [usbcore] [46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.c Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated. | ["https://git.kernel.org/stable/c/0f0654318e25b2c185e245ba4a591e42fabb5e59","https://git.kernel.org/stable/c/365ef7c4277fdd781a695c3553fa157d622d805d","https://git.kernel.org/stable/c/5ad898ae82412f8a689d59829804bff2999dd0ea","https://git.kernel.org/stable/c/6b99de301d78e1f5249e57ef2c32e1dec3df2bb1","https://git.kernel.org/stable/c/8fb9d412ebe2f245f13481e4624b40e651570cbd","https://git.kernel.org/stable/c/a57b0ebabe6862dce0a2e0f13e17941ad72fc56b","https://git.kernel.org/stable/c/af8e119f52e9c13e556be9e03f27957554a84656","https://git.kernel.org/stable/c/ef0a0e616b2789bb804a0ce5e161db03170a85b6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43829 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/qxl: Add check for drm_cvt_mode Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/3efe34f95b1ac8c138a46b14ce75956db0d6ee7c","https://git.kernel.org/stable/c/4b1f303bdeceac049e56e4b20eb5280bd9e02f4f","https://git.kernel.org/stable/c/4e87f592a46bb804d8f833da6ce702ae4b55053f","https://git.kernel.org/stable/c/62ef8d7816c8e4a6088275553818b9afc0ffaa03","https://git.kernel.org/stable/c/7bd09a2db0f617377027a2bb0b9179e6959edff3","https://git.kernel.org/stable/c/d4c57354a06cb4a77998ff8aa40af89eee30e07b","https://git.kernel.org/stable/c/f28b353c0c6c7831a70ccca881bf2db5e6785cdd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43846 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: lib: objagg: Fix general protection fault The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported. Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects. Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1]. Before fixing the root cause, error out when nesting happens and warn. [1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> | ["https://git.kernel.org/stable/c/1936fa05a180834c3b52e0439a6bddc07814d3eb","https://git.kernel.org/stable/c/22ae17a267f4812861f0c644186c3421ff97dbfc","https://git.kernel.org/stable/c/499f742fed42e74f1321f4b12ca196a66a2b49fc","https://git.kernel.org/stable/c/565213e005557eb6cc4e42189d26eb300e02f170","https://git.kernel.org/stable/c/5adc61d29bbb461d7f7c2b48dceaa90ecd182eb7","https://git.kernel.org/stable/c/8161263362154cbebfbf4808097b956a6a8cb98a","https://git.kernel.org/stable/c/b4a3a89fffcdf09702b1f161b914e52abca1894d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43911 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix NULL dereference at band check in starting tx ba session In MLD connection, link_data/link_conf are dynamically allocated. They don't point to vif->bss_conf. So, there will be no chanreq assigned to vif->bss_conf and then the chan will be NULL. Tweak the code to check ht_supported/vht_supported/has_he/has_eht on sta deflink. Crash log (with rtw89 version under MLO development): [ 9890.526087] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9890.526102] #PF: supervisor read access in kernel mode [ 9890.526105] #PF: error_code(0x0000) - not-present page [ 9890.526109] PGD 0 P4D 0 [ 9890.526114] Oops: 0000 [#1] PREEMPT SMP PTI [ 9890.526119] CPU: 2 PID: 6367 Comm: kworker/u16:2 Kdump: loaded Tainted: G OE 6.9.0 #1 [ 9890.526123] Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB3WW (2.73 ) 11/28/2018 [ 9890.526126] Workqueue: phy2 rtw89_core_ba_work [rtw89_core] [ 9890.526203] RIP: 0010:ieee80211_start_tx_ba_session (net/mac80211/agg-tx.c:618 (discriminator 1)) mac80211 [ 9890.526279] Code: f7 e8 d5 93 3e ea 48 83 c4 28 89 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 49 8b 84 24 e0 f1 ff ff 48 8b 80 90 1b 00 00 <83> 38 03 0f 84 37 fe ff ff bb ea ff ff ff eb cc 49 8b 84 24 10 f3 All code ======== 0: f7 e8 imul %eax 2: d5 (bad) 3: 93 xchg %eax,%ebx 4: 3e ea ds (bad) 6: 48 83 c4 28 add $0x28,%rsp a: 89 d8 mov %ebx,%eax c: 5b pop %rbx d: 41 5c pop %r12 f: 41 5d pop %r13 11: 41 5e pop %r14 13: 41 5f pop %r15 15: 5d pop %rbp 16: c3 retq 17: cc int3 18: cc int3 19: cc int3 1a: cc int3 1b: 49 8b 84 24 e0 f1 ff mov -0xe20(%r12),%rax 22: ff 23: 48 8b 80 90 1b 00 00 mov 0x1b90(%rax),%rax 2a:* 83 38 03 cmpl $0x3,(%rax) <-- trapping instruction 2d: 0f 84 37 fe ff ff je 0xfffffffffffffe6a 33: bb ea ff ff ff mov $0xffffffea,%ebx 38: eb cc jmp 0x6 3a: 49 rex.WB 3b: 8b .byte 0x8b 3c: 84 24 10 test %ah,(%rax,%rdx,1) 3f: f3 repz Code starting with the faulting instruction =========================================== 0: 83 38 03 cmpl $0x3,(%rax) 3: 0f 84 37 fe ff ff je 0xfffffffffffffe40 9: bb ea ff ff ff mov $0xffffffea,%ebx e: eb cc jmp 0xffffffffffffffdc 10: 49 rex.WB 11: 8b .byte 0x8b 12: 84 24 10 test %ah,(%rax,%rdx,1) 15: f3 repz [ 9890.526285] RSP: 0018:ffffb8db09013d68 EFLAGS: 00010246 [ 9890.526291] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9308e0d656c8 [ 9890.526295] RDX: 0000000000000000 RSI: ffffffffab99460b RDI: ffffffffab9a7685 [ 9890.526300] RBP: ffffb8db09013db8 R08: 0000000000000000 R09: 0000000000000873 [ 9890.526304] R10: ffff9308e0d64800 R11: 0000000000000002 R12: ffff9308e5ff6e70 [ 9890.526308] R13: ffff930952500e20 R14: ffff9309192a8c00 R15: 0000000000000000 [ 9890.526313] FS: 0000000000000000(0000) GS:ffff930b4e700000(0000) knlGS:0000000000000000 [ 9890.526316] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9890.526318] CR2: 0000000000000000 CR3: 0000000391c58005 CR4: 00000000001706f0 [ 9890.526321] Call Trace: [ 9890.526324] <TASK> [ 9890.526327] ? show_regs (arch/x86/kernel/dumpstack.c:479) [ 9890.526335] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 9890.526340] ? page_fault_oops (arch/x86/mm/fault.c:713) [ 9890.526347] ? search_module_extables (kernel/module/main.c:3256 (discriminator ---truncated--- | ["https://git.kernel.org/stable/c/021d53a3d87eeb9dbba524ac515651242a2a7e3b","https://git.kernel.org/stable/c/0acaf4a5025d6dafb7da787d2d4c47ed95e46ed6","https://git.kernel.org/stable/c/a53c2d847627b790fb3bd8b00e02c247941b17e0","https://git.kernel.org/stable/c/a5594c1e03b0df3908b1e1202a1ba34422eed0f6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checker before passing variables Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity. | ["https://git.kernel.org/stable/c/1686675405d07f35eae7ff3d13a530034b899df2","https://git.kernel.org/stable/c/4cc2a94d96caeb3c975acdae7351c2f997c32175","https://git.kernel.org/stable/c/8092aa3ab8f7b737a34b71f91492c676a843043a","https://git.kernel.org/stable/c/83c7f509ef087041604e9572938f82e18b724c9d","https://git.kernel.org/stable/c/d0b8b23b9c2ebec693a36fea518d8f13493ad655"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43909 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference for smu7 optimize the code to avoid pass a null pointer (hwmgr->backend) to function smu7_update_edc_leakage_table. | ["https://git.kernel.org/stable/c/09544cd95c688d3041328a4253bd7514972399bb","https://git.kernel.org/stable/c/1b8aa82b80bd947b68a8ab051d960a0c7935e22d","https://git.kernel.org/stable/c/37b9df457cbcf095963d18f17d6cb7dfa0a03fce","https://git.kernel.org/stable/c/7f56f050f02c27ed89cce1ea0c04b34abce32751","https://git.kernel.org/stable/c/c02c1960c93eede587576625a1221205a68a904f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38570 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix potential glock use-after-free on unmount When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically. Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace. This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released. To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks. As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead. | ["https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37","https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca","https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73","https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0","https://git.kernel.org/stable/c/0636b34b44589b142700ac137b5f69802cfe2e37","https://git.kernel.org/stable/c/501cd8fabf621d10bd4893e37f6ce6c20523c8ca","https://git.kernel.org/stable/c/d98779e687726d8f8860f1c54b5687eec5f63a73","https://git.kernel.org/stable/c/e42e8a24d7f02d28763d16ca7ec5fc6d1f142af0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40954 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: do not leave a dangling sk pointer, when socket creation fails It is possible to trigger a use-after-free by: * attaching an fentry probe to __sock_release() and the probe calling the bpf_get_socket_cookie() helper * running traceroute -I 1.1.1.1 on a freshly booted VM A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299 CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:117 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_report (mm/kasan/report.c:603) ? __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) kasan_check_range (mm/kasan/generic.c:183 mm/kasan/generic.c:189) __sock_gen_cookie (./arch/x86/include/asm/atomic64_64.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sock_diag.c:29) bpf_get_socket_ptr_cookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sock_diag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpf_prog_875642cf11f1d139___sock_release+0x6e/0x8e bpf_trampoline_6442506592+0x47/0xaf __sock_release (net/socket.c:652) __sock_create (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmem_cache_alloc_noprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) sk_prot_alloc (net/core/sock.c:2075) sk_alloc (net/core/sock.c:2134) inet_create (net/ipv4/af_inet.c:327 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 299 on cpu 2 at 78.328502s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) kasan_save_free_info (mm/kasan/generic.c:582) poison_slab_object (mm/kasan/common.c:242) __kasan_slab_free (mm/kasan/common.c:256) kmem_cache_free (mm/slub.c:4437 mm/slub.c:4511) __sk_destruct (net/core/sock.c:2117 net/core/sock.c:2208) inet_create (net/ipv4/af_inet.c:397 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1572) __sys_socket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) __x64_sys_socket (net/socket.c:1718) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Fix this by clearing the struct socket reference in sk_common_release() to cover all protocol families create functions, which may already attached the reference to the sk object with sock_init_data(). | ["https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5","https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9","https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2","https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069","https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e","https://git.kernel.org/stable/c/454c454ed645fed051216b79622f7cb69c1638f5","https://git.kernel.org/stable/c/5dfe2408fd7dc4d2e7ac38a116ff0a37b1cfd3b9","https://git.kernel.org/stable/c/6cd4a78d962bebbaf8beb7d2ead3f34120e3f7b2","https://git.kernel.org/stable/c/78e4aa528a7b1204219d808310524344f627d069","https://git.kernel.org/stable/c/893eeba94c40d513cd0fe6539330ebdaea208c0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38667 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: riscv: prevent pt_regs corruption for secondary idle threads Top of the kernel thread stack should be reserved for pt_regs. However this is not the case for the idle threads of the secondary boot harts. Their stacks overlap with their pt_regs, so both may get corrupted. Similar issue has been fixed for the primary hart, see c7cdd96eca28 ("riscv: prevent stack corruption by reserving task_pt_regs(p) early"). However that fix was not propagated to the secondary harts. The problem has been noticed in some CPU hotplug tests with V enabled. The function smp_callin stored several registers on stack, corrupting top of pt_regs structure including status field. As a result, kernel attempted to save or restore inexistent V context. | ["https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80","https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44","https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af","https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e","https://git.kernel.org/stable/c/0c1f28c32a194303da630fca89481334b9547b80","https://git.kernel.org/stable/c/3090c06d50eaa91317f84bf3eac4c265e6cb8d44","https://git.kernel.org/stable/c/a638b0461b58aa3205cd9d5f14d6f703d795b4af","https://git.kernel.org/stable/c/ea22d4195cca13d5fdbc4d6555a2dfb8a7867a9e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44974 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: avoid possible UaF when selecting endp select_local_address() and select_signal_address() both select an endpoint entry from the list inside an RCU protected section, but return a reference to it, to be read later on. If the entry is dereferenced after the RCU unlock, reading info could cause a Use-after-Free. A simple solution is to copy the required info while inside the RCU protected section to avoid any risk of UaF later. The address ID might need to be modified later to handle the ID0 case later, so a copy seems OK to deal with. | ["https://git.kernel.org/stable/c/0201d65d9806d287a00e0ba96f0321835631f63f","https://git.kernel.org/stable/c/2b4f46f9503633dade75cb796dd1949d0e6581a1","https://git.kernel.org/stable/c/48e50dcbcbaaf713d82bf2da5c16aeced94ad07d","https://git.kernel.org/stable/c/9a9afbbc3fbfca4975eea4aa5b18556db5a0c0b8","https://git.kernel.org/stable/c/ddee5b4b6a1cc03c1e9921cf34382e094c2009f1","https://git.kernel.org/stable/c/f2c865e9e3ca44fc06b5f73b29a954775e4dbb38"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50217 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). | ["https://git.kernel.org/stable/c/47a83f8df39545f3f552bb6a1b6d9c30e37621dd","https://git.kernel.org/stable/c/aec8e6bf839101784f3ef037dcdb9432c3f32343","http://www.openwall.com/lists/oss-security/2025/04/10/4","http://www.openwall.com/lists/oss-security/2025/04/10/5","http://www.openwall.com/lists/oss-security/2025/04/10/6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3623 | High | fixed |
|
A vulnerability was found in Linux Kernel. It has been declared as problematic. Affected by this vulnerability is the function follow_page_pte of the file mm/gup.c of the component BPF. The manipulation leads to race condition. The attack can be launched remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-211921 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://vuldb.com/?id.211921","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=fac35ba763ed07ba93154c95ffc0c4a55023707f","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://vuldb.com/?id.211921","https://www.debian.org/security/2023/dsa-5324"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48660 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully When running gpio test on nxp-ls1028 platform with below command gpiomon --num-events=3 --rising-edge gpiochip1 25 There will be a warning trace as below: Call trace: free_irq+0x204/0x360 lineevent_free+0x64/0x70 gpio_ioctl+0x598/0x6a0 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x5c/0x130 ...... el0t_64_sync+0x1a0/0x1a4 The reason of this issue is that calling request_threaded_irq() function failed, and then lineevent_free() is invoked to release the resource. Since the lineevent_state::irq was already set, so the subsequent invocation of free_irq() would trigger the above warning call trace. To fix this issue, set the lineevent_state::irq after the IRQ register successfully. | ["https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd","https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1","https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168","https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43","https://git.kernel.org/stable/c/657803b918e097e47d99d1489da83a603c36bcdd","https://git.kernel.org/stable/c/69bef19d6b9700e96285f4b4e28691cda3dcd0d1","https://git.kernel.org/stable/c/97da736cd11ae73bdf2f5e21e24446b8349e0168","https://git.kernel.org/stable/c/b1489043d3b9004dd8d5a0357b08b5f0e6691c43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: Prevent UAF in proc_cpuset_show() An UAF can happen when /proc/cpuset is read as reported in [1]. This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly. The race that cause this bug can be shown as below: (umount) | (cat /proc/<pid>/cpuset) css_release | proc_cpuset_show css_release_work_fn | css = task_get_css(tsk, cpuset_cgrp_id); css_free_rwork_fn | cgroup_path_ns(css->cgroup, ...); cgroup_destroy_root | mutex_lock(&cgroup_mutex); rebind_subsystems | cgroup_free_root | | // cgrp was freed, UAF | cgroup_path_ns_locked(cgrp,..); When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp. The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed. Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css. [1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd | ["https://git.kernel.org/stable/c/10aeaa47e4aa2432f29b3e5376df96d7dac5537a","https://git.kernel.org/stable/c/1be59c97c83ccd67a519d8a49486b3a8a73ca28a","https://git.kernel.org/stable/c/27d6dbdc6485d68075a0ebf8544d6425c1ed84bb","https://git.kernel.org/stable/c/29a8d4e02fd4840028c38ceb1536cc8f82a257d4","https://git.kernel.org/stable/c/29ac1d238b3bf126af36037df80d7ecc4822341e","https://git.kernel.org/stable/c/4e8d6ac8fc9f843e940ab7389db8136634e07989","https://git.kernel.org/stable/c/688325078a8b5badd6e07ae22b27cd04e9947aec","https://git.kernel.org/stable/c/96226fbed566f3f686f53a489a29846f2d538080"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35940 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pstore/zone: Add a null pointer check to the psz_kmsg_read kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. | ["https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb","https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682","https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc","https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8","https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041","https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70","https://git.kernel.org/stable/c/0ff96ec22a84d80a18d7ae8ca7eb111c34ee33bb","https://git.kernel.org/stable/c/635594cca59f9d7a8e96187600c34facb8bc0682","https://git.kernel.org/stable/c/6f9f2e498eae7897ba5d3e33908917f68ff4abcc","https://git.kernel.org/stable/c/98bc7e26e14fbb26a6abf97603d59532475e97f8","https://git.kernel.org/stable/c/98e2b97acb875d65bdfc75fc408e67975cef3041","https://git.kernel.org/stable/c/ec7256887d072f98c42cdbef4dcc80ddf84c7a70","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40905 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible race in __fib6_drop_pcpu_from() syzbot found a race in __fib6_drop_pcpu_from() [1] If compiler reads more than once (*ppcpu_rt), second read could read NULL, if another cpu clears the value in rt6_get_pcpu_route(). Add a READ_ONCE() to prevent this race. Also add rcu_read_lock()/rcu_read_unlock() because we rely on RCU protection while dereferencing pcpu_rt. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984 Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48 RSP: 0018:ffffc900040df070 EFLAGS: 00010206 RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16 RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091 RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8 R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 | ["https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914","https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf","https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef","https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12","https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f","https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d","https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5","https://git.kernel.org/stable/c/09e5a5a80e205922151136069e440477d6816914","https://git.kernel.org/stable/c/2498960dac9b6fc49b6d1574f7cd1a4872744adf","https://git.kernel.org/stable/c/7e796c3fefa8b17b30e7252886ae8cffacd2b9ef","https://git.kernel.org/stable/c/a0bc020592b54a8f3fa2b7f244b6e39e526c2e12","https://git.kernel.org/stable/c/b01e1c030770ff3b4fe37fc7cc6bca03f594133f","https://git.kernel.org/stable/c/c693698787660c97950bc1f93a8dd19d8307153d","https://git.kernel.org/stable/c/c90af1cced2f669a7b2304584be4ada495eaa0e5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42152 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a possible leak when destroy a ctrl during qp establishment In nvmet_sq_destroy we capture sq->ctrl early and if it is non-NULL we know that a ctrl was allocated (in the admin connect request handler) and we need to release pending AERs, clear ctrl->sqs and sq->ctrl (for nvme-loop primarily), and drop the final reference on the ctrl. However, a small window is possible where nvmet_sq_destroy starts (as a result of the client giving up and disconnecting) concurrently with the nvme admin connect cmd (which may be in an early stage). But *before* kill_and_confirm of sq->ref (i.e. the admin connect managed to get an sq live reference). In this case, sq->ctrl was allocated however after it was captured in a local variable in nvmet_sq_destroy. This prevented the final reference drop on the ctrl. Solve this by re-capturing the sq->ctrl after all inflight request has completed, where for sure sq->ctrl reference is final, and move forward based on that. This issue was observed in an environment with many hosts connecting multiple ctrls simoutanuosly, creating a delay in allocating a ctrl leading up to this race window. | ["https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa","https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1","https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33","https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da","https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5","https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4","https://git.kernel.org/stable/c/2f3c22b1d3d7e86712253244797a651998c141fa","https://git.kernel.org/stable/c/5502c1f1d0d7472706cc1f201aecf1c935d302d1","https://git.kernel.org/stable/c/818004f2a380420c19872171be716174d4985e33","https://git.kernel.org/stable/c/940a71f08ef153ef807f751310b0648d1fa5d0da","https://git.kernel.org/stable/c/b4fed1443a6571d49c6ffe7d97af3bbe5ee6dff5","https://git.kernel.org/stable/c/c758b77d4a0a0ed3a1292b3fd7a2aeccd1a169a4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3435 | Medium | N/A | A vulnerability classified as problematic has been found in Linux Kernel. This affects the function fib_nh_match of the file net/ipv4/fib_semantics.c of the component IPv4 Handler. The manipulation leads to out-of-bounds read. It is possible to initiate the attack remotely. It is recommended to apply a patch to fix this issue. The identifier VDB-210357 was assigned to this vulnerability. | ["https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/netdev/20221005181257.8897-1-dsahern%40kernel.org/T/#u","https://vuldb.com/?id.210357","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/netdev/20221005181257.8897-1-dsahern%40kernel.org/T/#u","https://vuldb.com/?id.210357"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35855 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update The rule activity update delayed work periodically traverses the list of configured rules and queries their activity from the device. As part of this task it accesses the entry pointed by 'ventry->entry', but this entry can be changed concurrently by the rehash delayed work, leading to a use-after-free [1]. Fix by closing the race and perform the activity query under the 'vregion->lock' mutex. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181 CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 | ["https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0","https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4","https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770","https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a","https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758","https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef","https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4","https://git.kernel.org/stable/c/1b73f6e4ea770410a937a8db98f77e52594d23a0","https://git.kernel.org/stable/c/79b5b4b18bc85b19d3a518483f9abbbe6d7b3ba4","https://git.kernel.org/stable/c/b183b915beef818a25e3154d719ca015a1ae0770","https://git.kernel.org/stable/c/b996e8699da810e4c915841d6aaef761007f933a","https://git.kernel.org/stable/c/c17976b42d546ee118ca300db559630ee96fb758","https://git.kernel.org/stable/c/e24d2487424779c02760ff50cd9021b8676e19ef","https://git.kernel.org/stable/c/feabdac2057e863d0e140a2adf3d232eb4882db4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27024 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/rds: fix WARNING in rds_conn_connect_if_down If connection isn't established yet, get_mr() will fail, trigger connection after get_mr(). | ["https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85","https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4","https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1","https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b","https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80","https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2","https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0","https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38","https://git.kernel.org/stable/c/2b505d05280739ce31d5708da840f42df827cb85","https://git.kernel.org/stable/c/786854141057751bc08eb26f1b02e97c1631c8f4","https://git.kernel.org/stable/c/907761307469adecb02461a14120e9a1812a5fb1","https://git.kernel.org/stable/c/997efea2bf3a4adb96c306b9ad6a91442237bf5b","https://git.kernel.org/stable/c/998fd719e6d6468b930ac0c44552ea9ff8b07b80","https://git.kernel.org/stable/c/9dfc15a10dfd44f8ff7f27488651cb5be6af83c2","https://git.kernel.org/stable/c/b562ebe21ed9adcf42242797dd6cb75beef12bf0","https://git.kernel.org/stable/c/c055fc00c07be1f0df7375ab0036cebd1106ed38","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46800 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sch/netem: fix use after free in netem_dequeue If netem_dequeue() enqueues packet to inner qdisc and that qdisc returns __NET_XMIT_STOLEN. The packet is dropped but qdisc_tree_reduce_backlog() is not called to update the parent's q.qlen, leading to the similar use-after-free as Commit e04991a48dbaf382 ("netem: fix return value if duplicate enqueue fails") Commands to trigger KASAN UaF: ip link add type dummy ip link set lo up ip link set dummy0 up tc qdisc add dev lo parent root handle 1: drr tc filter add dev lo parent 1: basic classid 1:1 tc class add dev lo classid 1:1 drr tc qdisc add dev lo parent 1:1 handle 2: netem tc qdisc add dev lo parent 2: handle 3: drr tc filter add dev lo parent 3: basic classid 3:1 action mirred egress redirect dev dummy0 tc class add dev lo classid 3:1 drr ping -c1 -W0.01 localhost # Trigger bug tc class del dev lo classid 1:1 tc class add dev lo classid 1:1 drr ping -c1 -W0.01 localhost # UaF | ["https://git.kernel.org/stable/c/14f91ab8d391f249b845916820a56f42cf747241","https://git.kernel.org/stable/c/295ad5afd9efc5f67b86c64fce28fb94e26dc4c9","https://git.kernel.org/stable/c/32008ab989ddcff1a485fa2b4906234c25dc5cd6","https://git.kernel.org/stable/c/3b3a2a9c6349e25a025d2330f479bc33a6ccb54a","https://git.kernel.org/stable/c/98c75d76187944296068d685dfd8a1e9fd8c4fdc","https://git.kernel.org/stable/c/db2c235682913a63054e741fe4e19645fdf2d68e","https://git.kernel.org/stable/c/dde33a9d0b80aae0c69594d1f462515d7ff1cb3d","https://git.kernel.org/stable/c/f0bddb4de043399f16d1969dad5ee5b984a64e7b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46853 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: nxp-fspi: fix the KASAN report out-of-bounds bug Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ============================================================== ---truncated--- | ["https://git.kernel.org/stable/c/09af8b0ba70072be831f3ec459f4063d570f9e24","https://git.kernel.org/stable/c/2a8787c1cdc7be24fdd8953ecd1a8743a1006235","https://git.kernel.org/stable/c/491f9646f7ac31af5fca71be1a3e5eb8aa7663ad","https://git.kernel.org/stable/c/609260542cf86b459c57618b8cdec8020394b7ad","https://git.kernel.org/stable/c/aa05db44db5f409f6d91c27b5737efb49fb45d9f","https://git.kernel.org/stable/c/af9ca9ca3e44f48b2a191e100d452fbf850c3d87","https://git.kernel.org/stable/c/d1a1dfcec77c57b1181da93d11a3db1bc4eefa97"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40958 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netns: Make get_net_ns() handle zero refcount net Syzkaller hit a warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0 Modules linked in: CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0xdf/0x1d0 Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1 RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72ac RDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001 RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139 R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4 R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040 FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f5b28f165d7 Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8 RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7 RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003 RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0 R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730 R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... This is trigger as below: ns0 ns1 tun_set_iff() //dev is tun0 tun->dev = dev //ip link set tun0 netns ns1 put_net() //ref is 0 __tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //addition on 0 Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this | ["https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef","https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b","https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55","https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b","https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940","https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876","https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0","https://git.kernel.org/stable/c/1b631bffcb2c09551888f3c723f4365c91fe05ef","https://git.kernel.org/stable/c/2b82028a1f5ee3a8e04090776b10c534144ae77b","https://git.kernel.org/stable/c/3a6cd326ead7c8bb1f64486789a01974a9f1ad55","https://git.kernel.org/stable/c/3af28df0d883e8c89a29ac31bc65f9023485743b","https://git.kernel.org/stable/c/cb7f811f638a14590ff98f53c6dd1fb54627d940","https://git.kernel.org/stable/c/ef0394ca25953ea0eddcc82feae1f750451f1876","https://git.kernel.org/stable/c/ff960f9d3edbe08a736b5a224d91a305ccc946b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38546 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: vc4: Fix possible null pointer dereference In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31","https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb","https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5","https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96","https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49","https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21","https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7","https://git.kernel.org/stable/c/2a345fe928c21de6f3c3c7230ff509d715153a31","https://git.kernel.org/stable/c/2d9adecc88ab678785b581ab021f039372c324cb","https://git.kernel.org/stable/c/42c22b63056cea259d5313bf138a834840af85a5","https://git.kernel.org/stable/c/6cf1874aec42058a5ad621a23b5b2f248def0e96","https://git.kernel.org/stable/c/80431ea3634efb47a3004305d76486db9dd8ed49","https://git.kernel.org/stable/c/bd7827d46d403f8cdb43d16744cb1114e4726b21","https://git.kernel.org/stable/c/c534b63bede6cb987c2946ed4d0b0013a52c5ba7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38548 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. | ["https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da","https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79","https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3","https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896","https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a","https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965","https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840","https://git.kernel.org/stable/c/32fb2ef124c3301656ac6c789a2ef35ef69a66da","https://git.kernel.org/stable/c/47889711da20be9b43e1e136e5cb68df37cbcc79","https://git.kernel.org/stable/c/85d1a27402f81f2e04b0e67d20f749c2a14edbb3","https://git.kernel.org/stable/c/89788cd9824c28ffcdea40232c458233353d1896","https://git.kernel.org/stable/c/935a92a1c400285545198ca2800a4c6c519c650a","https://git.kernel.org/stable/c/ca53b7efd4ba6ae92fd2b3085cb099c745e96965","https://git.kernel.org/stable/c/dcf53e6103b26e7458be71491d0641f49fbd5840"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42122 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL pointer check for kzalloc [Why & How] Check return pointer of kzalloc before using it. | ["https://git.kernel.org/stable/c/062edd612fcd300f0f79a36fca5b8b6a5e2fce70","https://git.kernel.org/stable/c/552e7938b4d7fe548fbf29b9950a14c6149d0470","https://git.kernel.org/stable/c/8e65a1b7118acf6af96449e1e66b7adbc9396912","https://git.kernel.org/stable/c/cd1e565a5b7fa60c349ca8a16db1e61715fe8230","https://git.kernel.org/stable/c/062edd612fcd300f0f79a36fca5b8b6a5e2fce70","https://git.kernel.org/stable/c/8e65a1b7118acf6af96449e1e66b7adbc9396912"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39507 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash problem in concurrent scenario When link status change, the nic driver need to notify the roce driver to handle this event, but at this time, the roce driver may uninit, then cause kernel crash. To fix the problem, when link status change, need to check whether the roce registered, and when uninit, need to wait link update finish. | ["https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4","https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48","https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa","https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63","https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd","https://git.kernel.org/stable/c/12cda920212a49fa22d9e8b9492ac4ea013310a4","https://git.kernel.org/stable/c/62b5dfb67bfa8bd0301bf3442004563495f9ee48","https://git.kernel.org/stable/c/689de7c3bfc7d47e0eacc641c4ce4a0f579aeefa","https://git.kernel.org/stable/c/6d0007f7b69d684879a0f598a042e40244d3cf63","https://git.kernel.org/stable/c/b2c5024b771cd1dd8175d5f6949accfadbab7edd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40957 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for PREROUTING hook, in PREROUTING hook, we should passing a valid indev, and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer dereference, as below: [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090 [74830.655633] #PF: supervisor read access in kernel mode [74830.657888] #PF: error_code(0x0000) - not-present page [74830.659500] PGD 0 P4D 0 [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI ... [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter] ... [74830.689725] Call Trace: [74830.690402] <IRQ> [74830.690953] ? show_trace_log_lvl+0x1c4/0x2df [74830.692020] ? show_trace_log_lvl+0x1c4/0x2df [74830.693095] ? ipt_do_table+0x286/0x710 [ip_tables] [74830.694275] ? __die_body.cold+0x8/0xd [74830.695205] ? page_fault_oops+0xac/0x140 [74830.696244] ? exc_page_fault+0x62/0x150 [74830.697225] ? asm_exc_page_fault+0x22/0x30 [74830.698344] ? rpfilter_mt+0x44/0x15e [ipt_rpfilter] [74830.699540] ipt_do_table+0x286/0x710 [ip_tables] [74830.700758] ? ip6_route_input+0x19d/0x240 [74830.701752] nf_hook_slow+0x3f/0xb0 [74830.702678] input_action_end_dx4+0x19b/0x1e0 [74830.703735] ? input_action_end_t+0xe0/0xe0 [74830.704734] seg6_local_input_core+0x2d/0x60 [74830.705782] lwtunnel_input+0x5b/0xb0 [74830.706690] __netif_receive_skb_one_core+0x63/0xa0 [74830.707825] process_backlog+0x99/0x140 [74830.709538] __napi_poll+0x2c/0x160 [74830.710673] net_rx_action+0x296/0x350 [74830.711860] __do_softirq+0xcb/0x2ac [74830.713049] do_softirq+0x63/0x90 input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally trigger a NULL dereference in rpfilter_mt()->rpfilter_is_loopback(): static bool rpfilter_is_loopback(const struct sk_buff *skb, const struct net_device *in) { // in is NULL return skb->pkt_type == PACKET_LOOPBACK || in->flags & IFF_LOOPBACK; } | ["https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c","https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779","https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d","https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6","https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4","https://git.kernel.org/stable/c/561475d53aa7e4511ee7cdba8728ded81cf1db1c","https://git.kernel.org/stable/c/9a3bc8d16e0aacd65c31aaf23a2bced3288a7779","https://git.kernel.org/stable/c/af90e3d73dc45778767b2fb6e7edd57ebe34380d","https://git.kernel.org/stable/c/d62df86c172033679d744f07d89e93e367dd11f6","https://git.kernel.org/stable/c/ec4d970b597ee5e17b0d8d73b7875197ce9a04d4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43817 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: missing check virtio Two missing check in virtio_net_hdr_to_skb() allowed syzbot to crash kernels again 1. After the skb_segment function the buffer may become non-linear (nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywhere the __skb_linearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skb_headlen(skb)) becomes true, which causes WARN_ON_ONCE in skb_checksum_help. 2. The struct sk_buff and struct virtio_net_hdr members must be mathematically related. (gso_size) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) must be greater than (needed) otherwise WARN_ON_ONCE. (remainder) may be 0 if division is without remainder. offset+2 (4191) > skb_headlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Found by Linux Verification Center (linuxtesting.org) with Syzkaller | ["https://git.kernel.org/stable/c/27874ca77bd2b05a3779c7b3a5c75d8dd7f0b40f","https://git.kernel.org/stable/c/5b1997487a3f3373b0f580c8a20b56c1b64b0775","https://git.kernel.org/stable/c/90d41ebe0cd4635f6410471efc1dd71b33e894cf","https://git.kernel.org/stable/c/e269d79c7d35aa3808b1f3c1737d63dab504ddc8","https://git.kernel.org/stable/c/e9164903b8b303c34723177b02fe91e49e3c4cd7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50304 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/31bd7378c6fe100a8af0e996ea0b5dafd3579df6","https://git.kernel.org/stable/c/6ac5dfa575136da8dd8a9e7c1437c41f3a593993","https://git.kernel.org/stable/c/90e0569dd3d32f4f4d2ca691d3fa5a8a14a13c12","https://git.kernel.org/stable/c/ce11424026cbf87d5861b09e5e33565ff7f2ec8d","https://git.kernel.org/stable/c/e0500e4373cd3d5eace1f1712444ab830b82c114","https://git.kernel.org/stable/c/f20fe2cfe06ca1b008b09da4f2b4e0c5547ccef6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action() syzbot is able to trigger the following crash [1], caused by unsafe ip6_dst_idev() use. Indeed ip6_dst_idev() can return NULL, and must always be checked. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267 Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4c RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700 RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760 RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000 R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00 FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09","https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95","https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa","https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290","https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0","https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747","https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa","https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff","https://git.kernel.org/stable/c/1876881c9a49613b5249fb400cbf53412d90cb09","https://git.kernel.org/stable/c/35297fc68de36826087e976f86a5b1f94fd0bf95","https://git.kernel.org/stable/c/4a5a573387da6a6b23a4cc62147453ff1bc32afa","https://git.kernel.org/stable/c/674c951ab8a23f7aff9b4c3f2f865901bc76a290","https://git.kernel.org/stable/c/7e3242c139c38e60844638e394c2877b16b396b0","https://git.kernel.org/stable/c/8745a8d74ba17dafe72b6ab461fa6c007d879747","https://git.kernel.org/stable/c/d101291b2681e5ab938554e3e323f7a7ee33e3aa","https://git.kernel.org/stable/c/ddec23f206a944c73bcc2724358b85388837daff","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20240926-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36960 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix invalid reads in fence signaled events Correctly set the length of the drm_event to the size of the structure that's actually used. The length of the drm_event was set to the parent structure instead of to the drm_vmw_event_fence which is supposed to be read. drm_read uses the length parameter to copy the event to the user space thus resuling in oob reads. | ["https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b","https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f","https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36","https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22","https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c","https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0","https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9","https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77","https://git.kernel.org/stable/c/0dbfc73670b357456196130551e586345ca48e1b","https://git.kernel.org/stable/c/2f527e3efd37c7c5e85e8aa86308856b619fa59f","https://git.kernel.org/stable/c/3cd682357c6167f636aec8ac0efaa8ba61144d36","https://git.kernel.org/stable/c/7b5fd3af4a250dd0a2a558e07b43478748eb5d22","https://git.kernel.org/stable/c/a37ef7613c00f2d72c8fc08bd83fb6cc76926c8c","https://git.kernel.org/stable/c/b7bab33c4623c66e3398d5253870d4e88c52dfc0","https://git.kernel.org/stable/c/cef0962f2d3e5fd0660c8efb72321083a1b531a9","https://git.kernel.org/stable/c/deab66596dfad14f1c54eeefdb72428340d72a77","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38430 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.9. ksmbd does not validate the SMB request protocol ID, leading to an out-of-bounds read. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9","https://security.netapp.com/advisory/ntap-20230831-0003/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=1c1bcf2d3ea061613119b534f57507c377df20f9","https://security.netapp.com/advisory/ntap-20230831-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38431 | Critical | fixed |
|
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/connection.c in ksmbd does not validate the relationship between the NetBIOS header's length field and the SMB header sizes, via pdu_size in ksmbd_conn_handler_loop, leading to an out-of-bounds read. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0","https://security.netapp.com/advisory/ntap-20230824-0011/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/smb/server?id=368ba06881c395f1c9a7ba22203cf8d78b4addc0","https://security.netapp.com/advisory/ntap-20230824-0011/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42895 | Medium | N/A | There is an infoleak vulnerability in the Linux kernel's net/bluetooth/l2cap_core.c's l2cap_parse_conf_req function which can be used to leak kernel pointers remotely. We recommend upgrading past commit https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e https://www.google.com/url | ["https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://kernel.dance/#b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://github.com/torvalds/linux/commit/b1a2cd50c0357f243b7435a732b4e62ba3157a2e","https://kernel.dance/#b1a2cd50c0357f243b7435a732b4e62ba3157a2e"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46808 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range [Why & How] ASSERT if return NULL from kcalloc. | ["https://git.kernel.org/stable/c/5524fa301ba649f8cf00848f91468e0ba7e4f24c","https://git.kernel.org/stable/c/ca0b0b0a22306f2e51105ac48f4a09c2fbbb504e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup: cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time. In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited(). | ["https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94","https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28","https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56","https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46","https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879","https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a","https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c","https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c","https://git.kernel.org/stable/c/02a4c0499fc3a02e992b4c69a9809912af372d94","https://git.kernel.org/stable/c/05b2cd6d33f700597e6f081b53c668a226a96d28","https://git.kernel.org/stable/c/217d1f44fff560b3995a685a60aa66e55a7f0f56","https://git.kernel.org/stable/c/22f00812862564b314784167a89f27b444f82a46","https://git.kernel.org/stable/c/53250b54c92fe087fd4b0c48f85529efe1ebd879","https://git.kernel.org/stable/c/72a3fe36cf9f0d030865e571f45a40f9c1e07e8a","https://git.kernel.org/stable/c/82075aff7ffccb1e72b0ac8aa349e473624d857c","https://git.kernel.org/stable/c/c0747d76eb05542b5d49f67069b64ef5ff732c6c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40961 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible NULL deref in fib6_nh_init() syzbot reminds us that in6_dev_get() can return NULL. fib6_nh_init() ip6_validate_gw( &idev ) ip6_route_check_nh( idev ) *idev = in6_dev_get(dev); // can be NULL Oops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7] CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606 Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b RSP: 0018:ffffc900032775a0 EFLAGS: 00010202 RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8 RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000 R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8 R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000 FS: 00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809 ip6_route_add+0x28/0x160 net/ipv6/route.c:3853 ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483 inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f940f07cea9 | ["https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6","https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade","https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668","https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4","https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403","https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727","https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc","https://git.kernel.org/stable/c/2eab4543a2204092c3a7af81d7d6c506e59a03a6","https://git.kernel.org/stable/c/3200ffeec4d59aad5bc9ca75d2c1fae47c0aeade","https://git.kernel.org/stable/c/4cdfe813015d5a24586bd0a84fa0fa6eb0a1f668","https://git.kernel.org/stable/c/88b9a55e2e35ea846d41f4efdc29d23345bd1aa4","https://git.kernel.org/stable/c/ae8d3d39efe366c2198f530e01e4bf07830bf403","https://git.kernel.org/stable/c/b6947723c9eabcab58cfb33cdb0a565a6aee6727","https://git.kernel.org/stable/c/de5ad4d45cd0128a2a37555f48ab69aa19d78adc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40984 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine." Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present. However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference. Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions. | ["https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3","https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98","https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d","https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0","https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c","https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f","https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239","https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04","https://git.kernel.org/stable/c/434c6b924e1f4c219aab2d9e05fe79c5364e37d3","https://git.kernel.org/stable/c/435ecc978c3d5d0c4e172ec5b956dc1904061d98","https://git.kernel.org/stable/c/6eca23100e9030725f69c1babacd58803f29ec8d","https://git.kernel.org/stable/c/a83e1385b780d41307433ddbc86e3c528db031f0","https://git.kernel.org/stable/c/ae465109d82f4fb03c5adbe85f2d6a6a3d59124c","https://git.kernel.org/stable/c/dc5017c57f5eee80020c73ff8b67ba7f9fd08b1f","https://git.kernel.org/stable/c/ddc1f5f124479360a1fd43f73be950781d172239","https://git.kernel.org/stable/c/e21a4c9129c72fa54dd00f5ebf71219b41d43c04"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45016 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netem: fix return value if duplicate enqueue fails There is a bug in netem_enqueue() introduced by commit 5845f706388a ("net: netem: fix skb length BUG_ON in __skb_to_sgvec") that can lead to a use-after-free. This commit made netem_enqueue() always return NET_XMIT_SUCCESS when a packet is duplicated, which can cause the parent qdisc's q.qlen to be mistakenly incremented. When this happens qlen_notify() may be skipped on the parent during destruction, leaving a dangling pointer for some classful qdiscs like DRR. There are two ways for the bug happen: - If the duplicated packet is dropped by rootq->enqueue() and then the original packet is also dropped. - If rootq->enqueue() sends the duplicated packet to a different qdisc and the original packet is dropped. In both cases NET_XMIT_SUCCESS is returned even though no packets are enqueued at the netem qdisc. The fix is to defer the enqueue of the duplicate packet until after the original packet has been guaranteed to return NET_XMIT_SUCCESS. | ["https://git.kernel.org/stable/c/0486d31dd8198e22b63a4730244b38fffce6d469","https://git.kernel.org/stable/c/52d99a69f3d556c6426048c9d481b912205919d8","https://git.kernel.org/stable/c/577d6c0619467fe90f7e8e57e45cb5bd9d936014","https://git.kernel.org/stable/c/759e3e8c4a6a6b4e52ebc4547123a457f0ce90d4","https://git.kernel.org/stable/c/c07ff8592d57ed258afee5a5e04991a48dbaf382","https://git.kernel.org/stable/c/c414000da1c2ea1ba9a5e5bb1a4ba774e51e202d","https://git.kernel.org/stable/c/e5bb2988a310667abed66c7d3ffa28880cf0f883"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40911 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Lock wiphy in cfg80211_get_station Wiphy should be locked before calling rdev_get_station() (see lockdep assert in ieee80211_get_station()). This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814) This happens because STA has time to disconnect and reconnect before batadv_v_elp_throughput_metric_update() delayed work gets scheduled. In this situation, ath10k_sta_state() can be in the middle of resetting arsta data when the work queue get chance to be scheduled and ends up accessing it. Locking wiphy prevents that. | ["https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a","https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba","https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae","https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76","https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9","https://git.kernel.org/stable/c/0ccc63958d8373e15a69f4f8069f3e78f7f3898a","https://git.kernel.org/stable/c/43e1eefb0b2094e2281150d87d09e8bc872b9fba","https://git.kernel.org/stable/c/642f89daa34567d02f312d03e41523a894906dae","https://git.kernel.org/stable/c/6d540b0317901535275020bd4ac44fac6439ca76","https://git.kernel.org/stable/c/dfd84ce41663be9ca3f69bd657c45f49b69344d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44944 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use helper function to calculate expect ID Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace. | ["https://git.kernel.org/stable/c/24f407042cf90b0872de667460230d8d50c06c39","https://git.kernel.org/stable/c/27662b46f2adaa52c1665a82af4b21c42c4337fd","https://git.kernel.org/stable/c/5e2c24f7b0911b15c29aefce760bcf770542fb61","https://git.kernel.org/stable/c/64c0b8e64be8368617ef08dfc59a3160563a1435","https://git.kernel.org/stable/c/66e7650dbbb8e236e781c670b167edc81e771450","https://git.kernel.org/stable/c/74de442b8e12a207c07953ee068009a7701aff8f","https://git.kernel.org/stable/c/782161895eb4ac45cf7cfa8db375bd4766cb8299","https://git.kernel.org/stable/c/eb4ca1a97e08ff5b920664ba292e576257e2d184","https://www.zerodayinitiative.com/advisories/ZDI-24-1182/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-8834 | Medium | N/A | KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc_{save,restore}_tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to panic. There were two commits that, according to the reporter, introduced the vulnerability: f024ee098476 ("KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures") 87a11bb6a7f7 ("KVM: PPC: Book3S HV: Work around XER[SO] bug in fake suspend mode") The former landed in 4.8, the latter in 4.17. This was fixed without realizing the impact in 4.18 with the following three commits, though it's believed the first is the only strictly necessary commit: 6f597c6b63b6 ("KVM: PPC: Book3S PR: Add guest MSR parameter for kvmppc_save_tm()/kvmppc_restore_tm()") 7b0e827c6970 ("KVM: PPC: Book3S HV: Factor fake-suspend handling out of kvmppc_save/restore_tm") 009c872a8bc4 ("KVM: PPC: Book3S PR: Move kvmppc_save_tm/kvmppc_restore_tm to separate file") | ["http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html","https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717","https://usn.ubuntu.com/4318-1/","https://usn.ubuntu.com/usn/usn-4318-1","https://www.openwall.com/lists/oss-security/2020/04/06/2","http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00035.html","https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1867717","https://usn.ubuntu.com/4318-1/","https://usn.ubuntu.com/usn/usn-4318-1","https://www.openwall.com/lists/oss-security/2020/04/06/2"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46740 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binder: fix UAF caused by offsets overwrite Binder objects are processed and copied individually into the target buffer during transactions. Any raw data in-between these objects is copied as well. However, this raw data copy lacks an out-of-bounds check. If the raw data exceeds the data section size then the copy overwrites the offsets section. This eventually triggers an error that attempts to unwind the processed objects. However, at this point the offsets used to index these objects are now corrupted. Unwinding with corrupted offsets can result in decrements of arbitrary nodes and lead to their premature release. Other users of such nodes are left with a dangling pointer triggering a use-after-free. This issue is made evident by the following KASAN report (trimmed): ================================================================== BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c Write of size 4 at addr ffff47fc91598f04 by task binder-util/743 CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1 Hardware name: linux,dummy-virt (DT) Call trace: _raw_spin_lock+0xe4/0x19c binder_free_buf+0x128/0x434 binder_thread_write+0x8a4/0x3260 binder_ioctl+0x18f0/0x258c [...] Allocated by task 743: __kmalloc_cache_noprof+0x110/0x270 binder_new_node+0x50/0x700 binder_transaction+0x413c/0x6da8 binder_thread_write+0x978/0x3260 binder_ioctl+0x18f0/0x258c [...] Freed by task 745: kfree+0xbc/0x208 binder_thread_read+0x1c5c/0x37d4 binder_ioctl+0x16d8/0x258c [...] ================================================================== To avoid this issue, let's check that the raw data copy is within the boundaries of the data section. | ["https://git.kernel.org/stable/c/109e845c1184c9f786d41516348ba3efd9112792","https://git.kernel.org/stable/c/1f33d9f1d9ac3f0129f8508925000900c2fe5bb0","https://git.kernel.org/stable/c/3a8154bb4ab4a01390a3abf1e6afac296e037da4","https://git.kernel.org/stable/c/4df153652cc46545722879415937582028c18af5","https://git.kernel.org/stable/c/4f79e0b80dc69bd5eaaed70f0df1b558728b4e59","https://git.kernel.org/stable/c/5a32bfd23022ffa7e152f273fa3fa29befb7d929","https://git.kernel.org/stable/c/eef79854a04feac5b861f94d7b19cbbe79874117"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49014 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix use-after-free in tun_detach() syzbot reported use-after-free in tun_detach() [1]. This causes call trace like below: ================================================================== BUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 Read of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673 CPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x461 mm/kasan/report.c:395 kasan_report+0xbf/0x1f0 mm/kasan/report.c:495 notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75 call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10237 [inline] netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351 tun_detach drivers/net/tun.c:704 [inline] tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467 __fput+0x27c/0xa90 fs/file_table.c:320 task_work_run+0x16f/0x270 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xb3d/0x2a30 kernel/exit.c:820 do_group_exit+0xd4/0x2a0 kernel/exit.c:950 get_signal+0x21b1/0x2440 kernel/signal.c:2858 arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869 exit_to_user_mode_loop kernel/entry/common.c:168 [inline] exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296 do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd The cause of the issue is that sock_put() from __tun_detach() drops last reference count for struct net, and then notifier_call_chain() from netdev_state_change() accesses that struct net. This patch fixes the issue by calling sock_put() from tun_detach() after all necessary accesses for the struct net has done. | ["https://git.kernel.org/stable/c/04b995e963229501401810dab89dc73e7f12d054","https://git.kernel.org/stable/c/16c244bc65d1175775325ec0489a5a5c830e02c7","https://git.kernel.org/stable/c/1f23f1890d91812c35d32eab1b49621b6d32dc7b","https://git.kernel.org/stable/c/4cde8da2d814a3b7b176db81922d4ddaad7c0f0e","https://git.kernel.org/stable/c/5daadc86f27ea4d691e2131c04310d0418c6cd12","https://git.kernel.org/stable/c/5f442e1d403e0496bacb74a58e2be7f500695e6f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48991 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths Any codepath that zaps page table entries must invoke MMU notifiers to ensure that secondary MMUs (like KVM) don't keep accessing pages which aren't mapped anymore. Secondary MMUs don't hold their own references to pages that are mirrored over, so failing to notify them can lead to page use-after-free. I'm marking this as addressing an issue introduced in commit f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages"), but most of the security impact of this only came in commit 27e1f8273113 ("khugepaged: enable collapse pmd for pte-mapped THP"), which actually omitted flushes for the removal of present PTEs, not just for the removal of empty page tables. | ["https://git.kernel.org/stable/c/1a3f8c6cd29d9078cc81b29d39d0e9ae1d6a03c3","https://git.kernel.org/stable/c/275c626c131cfe141beeb6c575e31fa53d32da19","https://git.kernel.org/stable/c/5450535901d89a5dcca5fbbc59a24fe89caeb465","https://git.kernel.org/stable/c/5ffc2a75534d9d74d49760f983f8eb675fa63d69","https://git.kernel.org/stable/c/7f445ca2e0e59c7971d0b7b853465e50844ab596","https://git.kernel.org/stable/c/c23105673228c349739e958fa33955ed8faddcaf","https://git.kernel.org/stable/c/f268f6cf875f3220afc77bdd0bf1bb136eb54db9","https://git.kernel.org/stable/c/ff2a1a6f869650aec99e9d070b5ab625bfbc5bc3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49015 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hsr: Fix potential use-after-free The skb is delivered to netif_rx() which may free it, after calling this, dereferencing skb may trigger use-after-free. | ["https://git.kernel.org/stable/c/4b351609af4fdbc23f79ab2b12748f4403ea9af4","https://git.kernel.org/stable/c/53a62c5efe91665f7a41fad0f888a96f94dc59eb","https://git.kernel.org/stable/c/7ca81a161e406834a1fdc405fc83a572bd14b8d9","https://git.kernel.org/stable/c/7e177d32442b7ed08a9fa61b61724abc548cb248","https://git.kernel.org/stable/c/8393ce5040803666bfa26a3a7bf41e44fab0ace9","https://git.kernel.org/stable/c/b35d899854d5d5d58eb7d7e7c0f61afc60d3a9e9","https://git.kernel.org/stable/c/dca370e575d9b6c983f5015e8dc035e23e219ee6","https://git.kernel.org/stable/c/f3add2b8cf620966de3ebfa07679ca12d33ec26f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48689 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: TX zerocopy should not sense pfmemalloc status We got a recent syzbot report [1] showing a possible misuse of pfmemalloc page status in TCP zerocopy paths. Indeed, for pages coming from user space or other layers, using page_is_pfmemalloc() is moot, and possibly could give false positives. There has been attempts to make page_is_pfmemalloc() more robust, but not using it in the first place in this context is probably better, removing cpu cycles. Note to stable teams : You need to backport 84ce071e38a6 ("net: introduce __skb_fill_page_desc_noacc") as a prereq. Race is more probable after commit c07aea3ef4d4 ("mm: add a signature in struct page") because page_is_pfmemalloc() is now using low order bit from page->lru.next, which can change more often than page->index. Low order bit should never be set for lru.next (when used as an anchor in LRU list), so KCSAN report is mostly a false positive. Backporting to older kernel versions seems not necessary. [1] BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0: __list_add include/linux/list.h:73 [inline] list_add include/linux/list.h:88 [inline] lruvec_add_folio include/linux/mm_inline.h:105 [inline] lru_add_fn+0x440/0x520 mm/swap.c:228 folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246 folio_batch_add_and_move mm/swap.c:263 [inline] folio_add_lru+0xf1/0x140 mm/swap.c:490 filemap_add_folio+0xf8/0x150 mm/filemap.c:948 __filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981 pagecache_get_page+0x26/0x190 mm/folio-compat.c:104 grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116 ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988 generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738 ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270 ext4_file_write_iter+0x2e3/0x1210 call_write_iter include/linux/fs.h:2187 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x468/0x760 fs/read_write.c:578 ksys_write+0xe8/0x1a0 fs/read_write.c:631 __do_sys_write fs/read_write.c:643 [inline] __se_sys_write fs/read_write.c:640 [inline] __x64_sys_write+0x3e/0x50 fs/read_write.c:640 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1: page_is_pfmemalloc include/linux/mm.h:1740 [inline] __skb_fill_page_desc include/linux/skbuff.h:2422 [inline] skb_fill_page_desc include/linux/skbuff.h:2443 [inline] tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018 do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075 tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline] tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150 inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833 kernel_sendpage+0x184/0x300 net/socket.c:3561 sock_sendpage+0x5a/0x70 net/socket.c:1054 pipe_to_sendpage+0x128/0x160 fs/splice.c:361 splice_from_pipe_feed fs/splice.c:415 [inline] __splice_from_pipe+0x222/0x4d0 fs/splice.c:559 splice_from_pipe fs/splice.c:594 [inline] generic_splice_sendpage+0x89/0xc0 fs/splice.c:743 do_splice_from fs/splice.c:764 [inline] direct_splice_actor+0x80/0xa0 fs/splice.c:931 splice_direct_to_actor+0x305/0x620 fs/splice.c:886 do_splice_direct+0xfb/0x180 fs/splice.c:974 do_sendfile+0x3bf/0x910 fs/read_write.c:1249 __do_sys_sendfile64 fs/read_write.c:1317 [inline] __se_sys_sendfile64 fs/read_write.c:1303 [inline] __x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xffffea0004a1d288 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 | ["https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775","https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83","https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915","https://git.kernel.org/stable/c/3261400639463a853ba2b3be8bd009c2a8089775","https://git.kernel.org/stable/c/6730c48ed6b0cd939fc9b30b2d621ce0b89bea83","https://git.kernel.org/stable/c/8527c9a6bf8e54fef0a8d3d7d8874a48c725c915"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46858 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: Fix uaf in __timer_delete_sync There are two paths to access mptcp_pm_del_add_timer, result in a race condition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry) In remove_anno_list_by_saddr(running on CPU2), after leaving the critical zone protected by "pm.lock", the entry will be released, which leads to the occurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1). Keeping a reference to add_timer inside the lock, and calling sk_stop_timer_sync() with this reference, instead of "entry->add_timer". Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock, do not directly access any members of the entry outside the pm lock, which can avoid similar "entry->x" uaf. | ["https://git.kernel.org/stable/c/12134a652b0a10064844ea235173e70246eba6dc","https://git.kernel.org/stable/c/3554482f4691571fc4b5490c17ae26896e62171c","https://git.kernel.org/stable/c/6452b162549c7f9ef54655d3fb9977b9192e6e5b","https://git.kernel.org/stable/c/67409b358500c71632116356a0b065f112d7b707","https://git.kernel.org/stable/c/b4cd80b0338945a94972ac3ed54f8338d2da2076"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26976 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: Always flush async #PF workqueue when vCPU is being destroyed Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its completion queue, e.g. when a VM and all its vCPUs is being destroyed. KVM must ensure that none of its workqueue callbacks is running when the last reference to the KVM _module_ is put. Gifting a reference to the associated VM prevents the workqueue callback from dereferencing freed vCPU/VM memory, but does not prevent the KVM module from being unloaded before the callback completes. Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will result in deadlock. async_pf_execute() can't return until kvm_put_kvm() finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes: WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm] Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events async_pf_execute [kvm] RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm] Call Trace: <TASK> async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> ---[ end trace 0000000000000000 ]--- INFO: task kworker/8:1:251 blocked for more than 120 seconds. Tainted: G W 6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/8:1 state:D stack:0 pid:251 ppid:2 flags:0x00004000 Workqueue: events async_pf_execute [kvm] Call Trace: <TASK> __schedule+0x33f/0xa40 schedule+0x53/0xc0 schedule_timeout+0x12a/0x140 __wait_for_common+0x8d/0x1d0 __flush_work.isra.0+0x19f/0x2c0 kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm] kvm_arch_destroy_vm+0x78/0x1b0 [kvm] kvm_put_kvm+0x1c1/0x320 [kvm] async_pf_execute+0x198/0x260 [kvm] process_one_work+0x145/0x2d0 worker_thread+0x27e/0x3a0 kthread+0xba/0xe0 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 </TASK> If kvm_clear_async_pf_completion_queue() actually flushes the workqueue, then there's no need to gift async_pf_execute() a reference because all invocations of async_pf_execute() will be forced to complete before the vCPU and its VM are destroyed/freed. And that in turn fixes the module unloading bug as __fput() won't do module_put() on the last vCPU reference until the vCPU has been freed, e.g. if closing the vCPU file also puts the last reference to the KVM module. Note that kvm_check_async_pf_completion() may also take the work item off the completion queue and so also needs to flush the work queue, as the work will not be seen by kvm_clear_async_pf_completion_queue(). Waiting on the workqueue could theoretically delay a vCPU due to waiting for the work to complete, but that's a very, very small chance, and likely a very small delay. kvm_arch_async_page_present_queued() unconditionally makes a new request, i.e. will effectively delay entering the guest, so the remaining work is really just: trace_kvm_async_pf_completed(addr, cr2_or_gpa); __kvm_vcpu_wake_up(vcpu); mmput(mm); and mmput() can't drop the last reference to the page tables if the vCPU is still alive, i.e. the vCPU won't get stuck tearing down page tables. Add a helper to do the flushing, specifically to deal with "wakeup all" work items, as they aren't actually work items, i.e. are never placed in a workqueue. Trying to flush a bogus workqueue entry rightly makes __flush_work() complain (kudos to whoever added that sanity check). Note, commit 5f6de5cbebee ("KVM: Prevent module exit until al ---truncated--- | ["https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157","https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750","https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb","https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac","https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98","https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5","https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff","https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b","https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264","https://git.kernel.org/stable/c/3d75b8aa5c29058a512db29da7cbee8052724157","https://git.kernel.org/stable/c/4f3a3bce428fb439c66a578adc447afce7b4a750","https://git.kernel.org/stable/c/82e25cc1c2e93c3023da98be282322fc08b61ffb","https://git.kernel.org/stable/c/83d3c5e309611ef593e2fcb78444fc8ceedf9bac","https://git.kernel.org/stable/c/a75afe480d4349c524d9c659b1a5a544dbc39a98","https://git.kernel.org/stable/c/ab2c2f5d9576112ad22cfd3798071cb74693b1f5","https://git.kernel.org/stable/c/b54478d20375874aeee257744dedfd3e413432ff","https://git.kernel.org/stable/c/caa9af2e27c275e089d702cfbaaece3b42bca31b","https://git.kernel.org/stable/c/f8730d6335e5f43d09151fca1f0f41922209a264","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48639 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix possible refcount leak in tc_new_tfilter() tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops. | ["https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88","https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596","https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a","https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5","https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7","https://git.kernel.org/stable/c/0559d91ee3a2cd81b15ad5cd507539d6da867f88","https://git.kernel.org/stable/c/8844c750eeb03452e2b3319c27a526f447b82596","https://git.kernel.org/stable/c/903f7d322c17d8e306d766404b4604e81653902a","https://git.kernel.org/stable/c/c2e1cfefcac35e0eea229e148c8284088ce437b5","https://git.kernel.org/stable/c/f8162aed962be8fa07445b2b5928e84ab40dd8d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52745 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/IPoIB: Fix legacy IPoIB due to wrong number of queues The cited commit creates child PKEY interfaces over netlink will multiple tx and rx queues, but some devices doesn't support more than 1 tx and 1 rx queues. This causes to a crash when traffic is sent over the PKEY interface due to the parent having a single queue but the child having multiple queues. This patch fixes the number of queues to 1 for legacy IPoIB at the earliest possible point in time. BUG: kernel NULL pointer dereference, address: 000000000000036b PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0xcb/0x450 Code: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a 01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202 RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00 RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40 R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000 R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000 FS: 00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_clone+0x55/0xd0 ip6_finish_output2+0x3fe/0x690 ip6_finish_output+0xfa/0x310 ip6_send_skb+0x1e/0x60 udp_v6_send_skb+0x1e5/0x420 udpv6_sendmsg+0xb3c/0xe60 ? ip_mc_finish_output+0x180/0x180 ? __switch_to_asm+0x3a/0x60 ? __switch_to_asm+0x34/0x60 sock_sendmsg+0x33/0x40 __sys_sendto+0x103/0x160 ? _copy_to_user+0x21/0x30 ? kvm_clock_get_cycles+0xd/0x10 ? ktime_get_ts64+0x49/0xe0 __x64_sys_sendto+0x25/0x30 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f9374f1ed14 Code: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14 RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030 RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc </TASK> | ["https://git.kernel.org/stable/c/1b4ef90cbcfa603b3bb536fbd6f261197012b6f6","https://git.kernel.org/stable/c/4a779187db39b2f32d048a752573e56e4e77807f","https://git.kernel.org/stable/c/7197460dcd43ff0e4a502ba855dd82d37c2848cc","https://git.kernel.org/stable/c/b1afb666c32931667c15ad1b58e7203f0119dcaf","https://git.kernel.org/stable/c/e632291a2dbce45a24cddeb5fe28fe71d724ba43","https://git.kernel.org/stable/c/1b4ef90cbcfa603b3bb536fbd6f261197012b6f6","https://git.kernel.org/stable/c/4a779187db39b2f32d048a752573e56e4e77807f","https://git.kernel.org/stable/c/7197460dcd43ff0e4a502ba855dd82d37c2848cc","https://git.kernel.org/stable/c/b1afb666c32931667c15ad1b58e7203f0119dcaf","https://git.kernel.org/stable/c/e632291a2dbce45a24cddeb5fe28fe71d724ba43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44950 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: fix invalid FIFO access with special register set When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading. Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register set Fix the problem by claiming the efr_lock mutex when accessing the Special register set. | ["https://git.kernel.org/stable/c/6a6730812220a9a5ce4003eb347da1ee5abd06b0","https://git.kernel.org/stable/c/7d3b793faaab1305994ce568b59d61927235f57b","https://git.kernel.org/stable/c/cc6a3f35bc9b3a8da1b195420a2e8d9fdadfa831","https://git.kernel.org/stable/c/dc5ead0e8fc5ef53b8553394d4aab60c277976b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-29581 | High | fixed |
|
Improper Update of Reference Count vulnerability in net/sched of Linux Kernel allows local attacker to cause privilege escalation to root. This issue affects: Linux Kernel versions prior to 5.18; version 4.14 and later versions. | ["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://www.openwall.com/lists/oss-security/2022/05/18/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8","https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8","https://security.netapp.com/advisory/ntap-20220629-0005/","https://www.debian.org/security/2022/dsa-5173","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/168191/Kernel-Live-Patch-Security-Notice-LSN-0089-1.html","http://www.openwall.com/lists/oss-security/2022/05/18/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3db09e762dc79584a69c10d74a6b98f89a9979f8","https://kernel.dance/#3db09e762dc79584a69c10d74a6b98f89a9979f8","https://security.netapp.com/advisory/ntap-20220629-0005/","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44977 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Validate TA binary size Add TA binary size validation to avoid OOB write. (cherry picked from commit c0a04e3570d72aaf090962156ad085e37c62e442) | ["https://git.kernel.org/stable/c/50553ea7cbd3344fbf40afb065f6a2d38171c1ad","https://git.kernel.org/stable/c/5ab8793b9a6cc059f503cbe6fe596f80765e0f19","https://git.kernel.org/stable/c/c99769bceab4ecb6a067b9af11f9db281eea3e2a","https://git.kernel.org/stable/c/e562415248f402203e7fb6d8c38c1b32fa99220f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50257 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: <TASK> get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0 cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template kfree(t) //removed from templ_list getinfo() t = xt_find_table_lock list_for_each_entry(tmpl, &xt_templates[af]...) if (strcmp(tmpl->name, name)) continue; //table not found try_module_get list_for_each_entry(t, &xt_net->tables[af]...) return t; //not get refcnt module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it. | ["https://git.kernel.org/stable/c/6a1f088f9807f5166f58902d26246d0b88da03a8","https://git.kernel.org/stable/c/ba22ea01348384df19cc1fabc7964be6e7189749","https://git.kernel.org/stable/c/bab3bb35c03b263c486833d50d50c081d9e9832b","https://git.kernel.org/stable/c/cb7c388b5967946f097afdb759b7c860305f2d96","https://git.kernel.org/stable/c/f48d258f0ac540f00fa617dac496c4c18b5dc2fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2318 | Medium | fixed |
|
There are use-after-free vulnerabilities caused by timer handler in net/rose/rose_timer.c of linux that allow attackers to crash linux kernel without any privileges. | ["https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2022/dsa-5191","https://github.com/torvalds/linux/commit/9cc02ede696272c5271a401e4f27c262359bc2f6","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2022/dsa-5191"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35896 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: validate user input for expected length I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt") setsockopt() @optlen argument should be taken into account before copying data. BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238 CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline] do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627 nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8 </TASK> Allocated by task 7238: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:4069 [inline] __kmalloc_noprof+0x200/0x410 mm/slub.c:4082 kmalloc_noprof include/linux/slab.h:664 [inline] __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x72/0x7a The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1) The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) page_type: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated--- | ["https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc","https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6","https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5","https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b","https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018","https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525","https://git.kernel.org/stable/c/0c83842df40f86e529db6842231154772c20edcc","https://git.kernel.org/stable/c/0f038242b77ddfc505bf4163d4904c1abd2e74d6","https://git.kernel.org/stable/c/18aae2cb87e5faa9c5bd865260ceadac60d5a6c5","https://git.kernel.org/stable/c/440e948cf0eff32cfe322dcbca3f2525354b159b","https://git.kernel.org/stable/c/58f2bfb789e6bd3bc24a2c9c1580f3c67aec3018","https://git.kernel.org/stable/c/81d51b9b7c95e791ba3c1a2dd77920a9d3b3f525","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20250321-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42722 | Medium | fixed |
|
In the Linux kernel 5.8 through 5.19.x before 5.19.16, local attackers able to inject WLAN frames into the mac80211 stack could cause a NULL pointer dereference denial-of-service attack against the beacon protection of P2P devices. | ["http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204125","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257","http://packetstormsecurity.com/files/169951/Kernel-Live-Patch-Security-Notice-LSN-0090-1.html","http://www.openwall.com/lists/oss-security/2022/10/13/5","https://bugzilla.suse.com/show_bug.cgi?id=1204125","https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5a381731ea0355459be09f","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://security.netapp.com/advisory/ntap-20230203-0008/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36014 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/arm/malidp: fix a possible null pointer dereference In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. | ["https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5","https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490","https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c","https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639","https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea","https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb","https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818","https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d","https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07","https://git.kernel.org/stable/c/335cc45ef2b81b68be63c698b4f867a530bdf7a5","https://git.kernel.org/stable/c/3e54d4e95120641216dfe91a6c49f116a9f68490","https://git.kernel.org/stable/c/565d9ad7e5a18eb69ed8b66a9e9bb3f45346520c","https://git.kernel.org/stable/c/93f76ec1eddce60dbb5885cbc0d7df54adee4639","https://git.kernel.org/stable/c/a1f95aede6285dba6dd036d907196f35ae3a11ea","https://git.kernel.org/stable/c/a5fa5b40a278a3ca978fed64707bd27614adb1eb","https://git.kernel.org/stable/c/b6cc5dd06336ed8bb3a7a1fc5aaf7d5e88bc0818","https://git.kernel.org/stable/c/b77620730f614059db2470e8ebab3e725280fc6d","https://git.kernel.org/stable/c/e4b52d49383306ef73fd1bd9102538beebb0fe07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42288 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix for possible memory corruption Init Control Block is dereferenced incorrectly. Correctly dereference ICB | ["https://git.kernel.org/stable/c/2a15b59a2c5afac89696e44acf5bbfc0599c6c5e","https://git.kernel.org/stable/c/571d7f2a08836698c2fb0d792236424575b9829b","https://git.kernel.org/stable/c/8192c533e89d9fb69b2490398939236b78cda79b","https://git.kernel.org/stable/c/87db8d7b7520e99de71791260989f06f9c94953d","https://git.kernel.org/stable/c/b0302ffc74123b6a99d7d1896fcd9b2e4072d9ce","https://git.kernel.org/stable/c/c03d740152f78e86945a75b2ad541bf972fab92a","https://git.kernel.org/stable/c/dae67169cb35a37ecccf60cfcd6bf93a1f4f5efb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43894 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/client: fix null pointer dereference in drm_client_modeset_probe In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is assigned to modeset->mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/113fd6372a5bb3689aba8ef5b8a265ed1529a78f","https://git.kernel.org/stable/c/24ddda932c43ffe156c7f3c568bed85131c63ae6","https://git.kernel.org/stable/c/5291d4f73452c91e8a11f71207617e3e234d418e","https://git.kernel.org/stable/c/612cae53e99ce32a58cb821b3b67199eb6e92dff","https://git.kernel.org/stable/c/c763dfe09425152b6bb0e348900a637c62c2ce52","https://git.kernel.org/stable/c/d64847c383100423aecb6ac5f18be5f4316d9d62","https://git.kernel.org/stable/c/d64fc94f7bb24fc2be0d6bd5df8df926da461a6d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2016-0774 | Medium | N/A | The (1) pipe_read and (2) pipe_write implementations in fs/pipe.c in a certain Linux kernel backport in the linux package before 3.2.73-2+deb7u3 on Debian wheezy and the kernel package before 3.10.0-229.26.2 on Red Hat Enterprise Linux (RHEL) 7.1 do not properly consider the side effects of failed __copy_to_user_inatomic and __copy_from_user_inatomic calls, which allows local users to cause a denial of service (system crash) or possibly gain privileges via a crafted application, aka an "I/O vector array overrun." NOTE: this vulnerability exists because of an incorrect fix for CVE-2015-1805. | ["http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00025.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00026.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00027.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00028.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00029.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00030.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00031.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00032.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00033.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00034.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00036.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00037.html","http://rhn.redhat.com/errata/RHSA-2016-0494.html","http://rhn.redhat.com/errata/RHSA-2016-0617.html","http://source.android.com/security/bulletin/2016-05-01.html","http://www.debian.org/security/2016/dsa-3503","http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html","http://www.securityfocus.com/bid/84126","http://www.ubuntu.com/usn/USN-2967-1","http://www.ubuntu.com/usn/USN-2967-2","http://www.ubuntu.com/usn/USN-2968-1","http://www.ubuntu.com/usn/USN-2968-2","https://bugzilla.redhat.com/show_bug.cgi?id=1303961","https://security-tracker.debian.org/tracker/CVE-2016-0774","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00025.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00026.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00027.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00028.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00029.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00030.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00031.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00032.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00033.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00034.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00036.html","http://lists.opensuse.org/opensuse-security-announce/2016-04/msg00037.html","http://rhn.redhat.com/errata/RHSA-2016-0494.html","http://rhn.redhat.com/errata/RHSA-2016-0617.html","http://source.android.com/security/bulletin/2016-05-01.html","http://www.debian.org/security/2016/dsa-3503","http://www.oracle.com/technetwork/topics/security/linuxbulletinapr2016-2952096.html","http://www.securityfocus.com/bid/84126","http://www.ubuntu.com/usn/USN-2967-1","http://www.ubuntu.com/usn/USN-2967-2","http://www.ubuntu.com/usn/USN-2968-1","http://www.ubuntu.com/usn/USN-2968-2","https://bugzilla.redhat.com/show_bug.cgi?id=1303961","https://security-tracker.debian.org/tracker/CVE-2016-0774"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35843 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Use device rbtree in iopf reporting path The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. | ["https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15","https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a","https://git.kernel.org/stable/c/3d39238991e745c5df85785604f037f35d9d1b15","https://git.kernel.org/stable/c/def054b01a867822254e1dda13d587f5c7a99e2a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-43750 | Medium | fixed |
|
drivers/usb/mon/mon_bin.c in usbmon in the Linux kernel before 5.19.15 and 6.x before 6.0.1 allows a user-space client to corrupt the monitor's internal memory. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198","https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.15","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a659daf63d16aa883be42f3f34ff84235c302198","https://github.com/torvalds/linux/commit/a659daf63d16aa883be42f3f34ff84235c302198","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43892 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one. | ["https://git.kernel.org/stable/c/37a060b64ae83b76600d187d76591ce488ab836b","https://git.kernel.org/stable/c/51c0b1bb7541f8893ec1accba59eb04361a70946","https://git.kernel.org/stable/c/56fd70f4aa8b82199dbe7e99366b1fd7a04d86fb","https://git.kernel.org/stable/c/912736a0435ef40e6a4ae78197ccb5553cb80b05","https://git.kernel.org/stable/c/9972605a238339b85bd16b084eed5f18414d22db","https://git.kernel.org/stable/c/e6cc9ff2ac0b5df9f25eb790934c3104f6710278"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix coverity issue with unintentional integer overflow 1. Instead of multiplying 2 variable of different types. Change to assign a value of one variable and then multiply the other variable. 2. Add a int variable for multiplier calculation instead of calculating different types multiplier with dma_addr_t variable directly. | ["https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396","https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c","https://git.kernel.org/stable/c/a12bd675100531f9fb4508fd4430dd1632325a0e","https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7","https://git.kernel.org/stable/c/0d8a1df39d3fc34560e2cc663b5c340d06a25396","https://git.kernel.org/stable/c/96312a251d4dcee5d36e32edba3002bfde0ddd9c","https://git.kernel.org/stable/c/b0b0d811eac6b4c52cb9ad632fa6384cf48869e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36923 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/9p: fix uninitialized values during inode evict If an iget fails due to not being able to retrieve information from the server then the inode structure is only partially initialized. When the inode gets evicted, references to uninitialized structures (like fscache cookies) were being made. This patch checks for a bad_inode before doing anything other than clearing the inode from the cache. Since the inode is bad, it shouldn't have any state associated with it that needs to be written back (and there really isn't a way to complete those anyways). | ["https://git.kernel.org/stable/c/18cf7026355187b8d2b4cdfed61dbf873e9d29ff","https://git.kernel.org/stable/c/1b4cb6e91f19b81217ad98142ee53a1ab25893fd","https://git.kernel.org/stable/c/3a741b80b3457f079cf637e47800fb7bf8038ad6","https://git.kernel.org/stable/c/6630036b7c228f57c7893ee0403e92c2db2cd21d","https://git.kernel.org/stable/c/1b4cb6e91f19b81217ad98142ee53a1ab25893fd","https://git.kernel.org/stable/c/6630036b7c228f57c7893ee0403e92c2db2cd21d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40995 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc() syzbot found hanging tasks waiting on rtnl_lock [1] A reproducer is available in the syzbot bug. When a request to add multiple actions with the same index is sent, the second request will block forever on the first request. This holds rtnl_lock, and causes tasks to hang. Return -EAGAIN to prevent infinite looping, while keeping documented behavior. [1] INFO: task kworker/1:0:5088 blocked for more than 143 seconds. Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000 Workqueue: events_power_efficient reg_check_chans_work Call Trace: <TASK> context_switch kernel/sched/core.c:5409 [inline] __schedule+0xf15/0x5d00 kernel/sched/core.c:6746 __schedule_loop kernel/sched/core.c:6823 [inline] schedule+0xe7/0x350 kernel/sched/core.c:6838 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895 __mutex_lock_common kernel/locking/mutex.c:684 [inline] __mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752 wiphy_lock include/net/cfg80211.h:5953 [inline] reg_leave_invalid_chans net/wireless/reg.c:2466 [inline] reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481 | ["https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74","https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da","https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2","https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4","https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335","https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90","https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6","https://git.kernel.org/stable/c/0d8a2d287c8a394c0d4653f0c6c7be4c688e5a74","https://git.kernel.org/stable/c/25987a97eec4d5f897cd04ee1b45170829c610da","https://git.kernel.org/stable/c/5f926aa96b08b6c47178fe1171e7ae331c695fc2","https://git.kernel.org/stable/c/6fc78d67f51aeb9a542d39a8714e16bc411582d4","https://git.kernel.org/stable/c/7a0e497b597df7c4cf2b63fc6e9188b6cabe5335","https://git.kernel.org/stable/c/c6a7da65a296745535a964be1019ec7691b0cb90","https://git.kernel.org/stable/c/d864319871b05fadd153e0aede4811ca7008f5d6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48642 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain() It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error. | ["https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852","https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714","https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac","https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88","https://git.kernel.org/stable/c/08d7524f366a886b99b1630a24a27dd6e0d7f852","https://git.kernel.org/stable/c/985b031667c3177b9e7fb9787b989628e4271714","https://git.kernel.org/stable/c/9a4d6dd554b86e65581ef6b6638a39ae079b17ac","https://git.kernel.org/stable/c/b043a525a3f5520abb676a7cd8f6328fdf959e88"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52702 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: openvswitch: fix possible memory leak in ovs_meter_cmd_set() old_meter needs to be free after it is detached regardless of whether the new meter is successfully attached. | ["https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536","https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5","https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6","https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e","https://git.kernel.org/stable/c/1563e998a938f095548054ef09e277b562b79536","https://git.kernel.org/stable/c/2fa28f5c6fcbfc794340684f36d2581b4f2d20b5","https://git.kernel.org/stable/c/c0f65ee0a3329eb4b94beaef0268633696e2d0c6","https://git.kernel.org/stable/c/e336a9e08618203a456fb5367f1387b14554f55e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49013 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: fix memory leak in sctp_stream_outq_migrate() When sctp_stream_outq_migrate() is called to release stream out resources, the memory pointed to by prio_head in stream out is not released. The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [<ffffffff81b215c6>] kmalloc_trace+0x26/0x60 [<ffffffff88ae517c>] sctp_sched_prio_set+0x4cc/0x770 [<ffffffff88ad64f2>] sctp_stream_init_ext+0xd2/0x1b0 [<ffffffff88aa2604>] sctp_sendmsg_to_asoc+0x1614/0x1a30 [<ffffffff88ab7ff1>] sctp_sendmsg+0xda1/0x1ef0 [<ffffffff87f765ed>] inet_sendmsg+0x9d/0xe0 [<ffffffff8754b5b3>] sock_sendmsg+0xd3/0x120 [<ffffffff8755446a>] __sys_sendto+0x23a/0x340 [<ffffffff87554651>] __x64_sys_sendto+0xe1/0x1b0 [<ffffffff89978b49>] do_syscall_64+0x39/0xb0 [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/0dfb9a566327182387c90100ea54d8426cee8c67","https://git.kernel.org/stable/c/176ee6c673ccd118e9392fd2dbb165423bdb99ca","https://git.kernel.org/stable/c/9ed7bfc79542119ac0a9e1ce8a2a5285e43433e9","https://git.kernel.org/stable/c/a7555681e50bdebed2c40ff7404ee73c2e932993","https://git.kernel.org/stable/c/fa20f88271259d42ebe66f0a8c4c20199e888c99"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52618 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block/rnbd-srv: Check for unlikely string overflow Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present). | ["https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827","https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7","https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41","https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339","https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f","https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7","https://git.kernel.org/stable/c/5b9ea86e662035a886ccb5c76d56793cba618827","https://git.kernel.org/stable/c/95bc866c11974d3e4a9d922275ea8127ff809cf7","https://git.kernel.org/stable/c/9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41","https://git.kernel.org/stable/c/a2c6206f18104fba7f887bf4dbbfe4c41adc4339","https://git.kernel.org/stable/c/af7bbdac89739e2e7380387fda598848d3b7010f","https://git.kernel.org/stable/c/f6abd5e17da33eba15df2bddc93413e76c2b55f7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48638 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cgroup: cgroup_get_from_id() must check the looked-up kn is a directory cgroup has to be one kernfs dir, otherwise kernel panic is caused, especially cgroup id is provide from userspace. | ["https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b","https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad","https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37","https://git.kernel.org/stable/c/1e9571887f97b17cf3ffe9aa4da89090ea60988b","https://git.kernel.org/stable/c/8484a356cee8ce3d6a8e6266ff99be326e9273ad","https://git.kernel.org/stable/c/df02452f3df069a59bc9e69c84435bf115cb6e37"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26958 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfs: fix UAF in direct writes In production we have been hitting the following warning consistently ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0 Workqueue: nfsiod nfs_direct_write_schedule_work [nfs] RIP: 0010:refcount_warn_saturate+0x9c/0xe0 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x9f/0x130 ? refcount_warn_saturate+0x9c/0xe0 ? report_bug+0xcc/0x150 ? handle_bug+0x3d/0x70 ? exc_invalid_op+0x16/0x40 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0x9c/0xe0 nfs_direct_write_schedule_work+0x237/0x250 [nfs] process_one_work+0x12f/0x4a0 worker_thread+0x14e/0x3b0 ? ZSTD_getCParams_internal+0x220/0x220 kthread+0xdc/0x120 ? __btf_name_valid+0xa0/0xa0 ret_from_fork+0x1f/0x30 This is because we're completing the nfs_direct_request twice in a row. The source of this is when we have our commit requests to submit, we process them and send them off, and then in the completion path for the commit requests we have if (nfs_commit_end(cinfo.mds)) nfs_direct_write_complete(dreq); However since we're submitting asynchronous requests we sometimes have one that completes before we submit the next one, so we end up calling complete on the nfs_direct_request twice. The only other place we use nfs_generic_commit_list() is in __nfs_commit_inode, which wraps this call in a nfs_commit_begin(); nfs_commit_end(); Which is a common pattern for this style of completion handling, one that is also repeated in the direct code with get_dreq()/put_dreq() calls around where we process events as well as in the completion paths. Fix this by using the same pattern for the commit requests. Before with my 200 node rocksdb stress running this warning would pop every 10ish minutes. With my patch the stress test has been running for several hours without popping. | ["https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af","https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab","https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3","https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5","https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f","https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95","https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605","https://git.kernel.org/stable/c/17f46b803d4f23c66cacce81db35fef3adb8f2af","https://git.kernel.org/stable/c/1daf52b5ffb24870fbeda20b4967526d8f9e12ab","https://git.kernel.org/stable/c/3abc2d160ed8213948b147295d77d44a22c88fa3","https://git.kernel.org/stable/c/4595d90b5d2ea5fa4d318d13f59055aa4bf3e7f5","https://git.kernel.org/stable/c/80d24b308b7ee7037fc90d8ac99f6f78df0a256f","https://git.kernel.org/stable/c/cf54f66e1dd78990ec6b32177bca7e6ea2144a95","https://git.kernel.org/stable/c/e25447c35f8745337ea8bc0c9697fcac14df8605","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35929 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock() For the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and CONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE() in the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions: CPU2 CPU11 kthread rcu_nocb_cb_kthread ksys_write rcu_do_batch vfs_write rcu_torture_timer_cb proc_sys_write __kmem_cache_free proc_sys_call_handler kmemleak_free drop_caches_sysctl_handler delete_object_full drop_slab __delete_object shrink_slab put_object lazy_rcu_shrink_scan call_rcu rcu_nocb_flush_bypass __call_rcu_commn rcu_nocb_bypass_lock raw_spin_trylock(&rdp->nocb_bypass_lock) fail atomic_inc(&rdp->nocb_lock_contended); rcu_nocb_wait_contended WARN_ON_ONCE(smp_processor_id() != rdp->cpu); WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended)) | |_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __| Reproduce this bug with "echo 3 > /proc/sys/vm/drop_caches". This commit therefore uses rcu_nocb_try_flush_bypass() instead of rcu_nocb_flush_bypass() in lazy_rcu_shrink_scan(). If the nocb_bypass queue is being flushed, then rcu_nocb_try_flush_bypass will return directly. | ["https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc","https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a","https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f","https://git.kernel.org/stable/c/4d58c9fb45c70e62c19e8be3f3605889c47601bc","https://git.kernel.org/stable/c/927d1f4f77e4784ab3944a9df86ab14d1cd3185a","https://git.kernel.org/stable/c/dda98810b552fc6bf650f4270edeebdc2f28bd3f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36921 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: guard against invalid STA ID on removal Guard against invalid station IDs in iwl_mvm_mld_rm_sta_id as that would result in out-of-bounds array accesses. This prevents issues should the driver get into a bad state during error handling. | ["https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f","https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294","https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f","https://git.kernel.org/stable/c/17f64517bf5c26af56b6c3566273aad6646c3c4f","https://git.kernel.org/stable/c/94f80a8ec15e238b78521f20f8afaed60521a294","https://git.kernel.org/stable/c/fab21d220017daa5fd8a3d788ff25ccfecfaae2f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42301 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] | ["https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8","https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d","https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a","https://git.kernel.org/stable/c/7f4da759092a1a6ce35fb085182d02de8cc4cc84","https://git.kernel.org/stable/c/a44f88f7576bc1916d8d6293f5c62fbe7cbe03e0","https://git.kernel.org/stable/c/ab11dac93d2d568d151b1918d7b84c2d02bacbd5","https://git.kernel.org/stable/c/b579ea3516c371ecf59d073772bc45dfd28c8a0e","https://git.kernel.org/stable/c/c719b393374d3763e64900ee19aaed767d5a08d6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42302 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. (On resume from system sleep, IRQs are not enabled until after the resume_noirq phase. And runtime resume is always awaited before a PCI device is removed.) However starting with v6.3, pci_bridge_wait_for_secondary_bus() is also called on a DPC event. Commit 53b54ad074de ("PCI/DPC: Await readiness of secondary bus after reset"), which introduced that, failed to appreciate that pci_bridge_wait_for_secondary_bus() now needs to hold a reference on the child device because dpc_handler() and pciehp may indeed run concurrently. The commit was backported to v5.10+ stable kernels, so that's the oldest one affected. Add the missing reference acquisition. Abridged stack trace: BUG: unable to handle page fault for address: 00000000091400c0 CPU: 15 PID: 2464 Comm: irq/53-pcie-dpc 6.9.0 RIP: pci_bus_read_config_dword+0x17/0x50 pci_dev_wait() pci_bridge_wait_for_secondary_bus() dpc_reset_link() pcie_do_recovery() dpc_handler() | ["https://git.kernel.org/stable/c/11a1f4bc47362700fcbde717292158873fb847ed","https://git.kernel.org/stable/c/2c111413f38ca5cf87557cab89f6d82b0e3433e7","https://git.kernel.org/stable/c/2cc8973bdc4d6c928ebe38b88090a2cdfe81f42f","https://git.kernel.org/stable/c/b16f3ea1db47a6766a9f1169244cf1fc287a7c62","https://git.kernel.org/stable/c/c52f9e1a9eb40f13993142c331a6cfd334d4b91d","https://git.kernel.org/stable/c/f63df70b439bb8331358a306541893bf415bf1da"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43858 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix array-index-out-of-bounds in diFree | ["https://git.kernel.org/stable/c/538a27c8048f081a5ddd286f886eb986fbbc7f80","https://git.kernel.org/stable/c/55b732c8b09b41148eaab2fa8e31b0af47671e00","https://git.kernel.org/stable/c/63f7fdf733add82f126ea00e2e48f6eba15ac4b9","https://git.kernel.org/stable/c/6aa6892a90a5a7fabffe5692ab9f06a7a46c6e42","https://git.kernel.org/stable/c/8d8f9a477de0d7962342eedf2a599215b7c63d28","https://git.kernel.org/stable/c/9b3a4345957f5372041bc4f59de322f62653e862","https://git.kernel.org/stable/c/f73f969b2eb39ad8056f6c7f3a295fa2f85e313a","https://git.kernel.org/stable/c/ff14eadc278663cac69d57d3ca7fb2f394e1f8a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46813 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_index before accessing dc->links[] [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index. This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity. | ["https://git.kernel.org/stable/c/032c5407a608ac3b2a98bf4fbda27d12c20c5887","https://git.kernel.org/stable/c/8aa2864044b9d13e95fe224f32e808afbf79ecdf","https://git.kernel.org/stable/c/ac04759b4a002969cf0f1384f1b8bb2001cfa782"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48691 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: clean up hook list when offload flags check fails splice back the hook list so nft_chain_release_hook() has a chance to release the hooks. BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83a8c59b>] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [<ffffffff83a9239a>] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline] [<ffffffff83a9239a>] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [<ffffffff83a9b14b>] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218 [<ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [<ffffffff83a3d6a6>] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [<ffffffff83a3db79>] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline] [<ffffffff83a3db79>] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [<ffffffff83a13b17>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff83a13b17>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff83a13fd6>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff83865ab6>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff83865ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8386601c>] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482 [<ffffffff8386a918>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff8386aaa8>] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [<ffffffff845e5955>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e5955>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157","https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65","https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4","https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5","https://git.kernel.org/stable/c/1ce55ec5cb7c573c983dffbe290b8d17caf1f157","https://git.kernel.org/stable/c/77972a36ecc4db7fc7c68f0e80714263c5f03f65","https://git.kernel.org/stable/c/910891a2a44cdc49efcc4fe7459c1085ba00d0f4","https://git.kernel.org/stable/c/94ed8eeb8d9aeb00e4f4e19b83a2e28b6442fbc5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42154 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp_metrics: validate source addr length I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4 is at least 4 bytes long, and the policy doesn't have an entry for this attribute at all (neither does it for IPv6 but v6 is manually validated). | ["https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9","https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c","https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3","https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321","https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff","https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99","https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98","https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6","http://www.openwall.com/lists/oss-security/2024/09/24/3","http://www.openwall.com/lists/oss-security/2024/09/24/4","http://www.openwall.com/lists/oss-security/2024/09/25/3","https://git.kernel.org/stable/c/19d997b59fa1fd7a02e770ee0881c0652b9c32c9","https://git.kernel.org/stable/c/2a2e79dbe2236a1289412d2044994f7ab419b44c","https://git.kernel.org/stable/c/31f03bb04146c1c6df6c03e9f45401f5f5a985d3","https://git.kernel.org/stable/c/3d550dd5418729a6e77fe7721d27adea7152e321","https://git.kernel.org/stable/c/66be40e622e177316ae81717aa30057ba9e61dff","https://git.kernel.org/stable/c/8c2debdd170e395934ac0e039748576dfde14e99","https://git.kernel.org/stable/c/cdffc358717e436bb67122bb82c1a2a26e050f98","https://git.kernel.org/stable/c/ef7c428b425beeb52b894e16f1c4b629d6cebfb6","https://security.netapp.com/advisory/ntap-20240828-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: af_unix: Get user_ns from in_skb in unix_diag_get_exact(). Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed the root cause: in unix_diag_get_exact(), the newly allocated skb does not have sk. [2] We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to sk_diag_fill(). [0]: BUG: kernel NULL pointer dereference, address: 0000000000000270 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014 RIP: 0010:sk_user_ns include/net/sock.h:920 [inline] RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline] RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170 Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8 54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b 9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d RSP: 0018:ffffc90000d67968 EFLAGS: 00010246 RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270 RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000 R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800 R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940 FS: 00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> unix_diag_get_exact net/unix/diag.c:285 [inline] unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317 __sock_diag_cmd net/core/sock_diag.c:235 [inline] sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2476 ___sys_sendmsg net/socket.c:2530 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2559 __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4697f9 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9 RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003 RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80 R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0 </TASK> Modules linked in: CR2: 0000000000000270 [1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/ [2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/ | ["https://git.kernel.org/stable/c/575a6266f63dbb3b8eb1da03671451f0d81b8034","https://git.kernel.org/stable/c/5c014eb0ed6c8c57f483e94cc6e90f34ce426d91","https://git.kernel.org/stable/c/9c1d6f79a2c7b8221dcec27defc6dc461052ead4","https://git.kernel.org/stable/c/b3abe42e94900bdd045c472f9c9be620ba5ce553","https://git.kernel.org/stable/c/c66d78aee55dab72c92020ebfbebc464d4f5dd2a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48977 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rcv_filter Analogue to commit 8aa59e355949 ("can: af_can: fix NULL pointer dereference in can_rx_register()") we need to check for a missing initialization of ml_priv in the receive path of CAN frames. Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct net_device") the check for dev->type to be ARPHRD_CAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize ml_priv accordingly. | ["https://git.kernel.org/stable/c/0acc442309a0a1b01bcdaa135e56e6398a49439c","https://git.kernel.org/stable/c/3982652957e8d79ac32efcb725450580650a8644","https://git.kernel.org/stable/c/c142cba37de29f740a3852f01f59876af8ae462a","https://git.kernel.org/stable/c/c42221efb1159d6a3c89e96685ee38acdce86b6f","https://git.kernel.org/stable/c/fcc63f2f7ee3038d53216edd0d8291e57c752557"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48986 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix gup_pud_range() for dax For dax pud, pud_huge() returns true on x86. So the function works as long as hugetlb is configured. However, dax doesn't depend on hugetlb. Commit 414fd080d125 ("mm/gup: fix gup_pmd_range() for dax") fixed devmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as well. This fixes the below kernel panic: general protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP < snip > Call Trace: <TASK> get_user_pages_fast+0x1f/0x40 iov_iter_get_pages+0xc6/0x3b0 ? mempool_alloc+0x5d/0x170 bio_iov_iter_get_pages+0x82/0x4e0 ? bvec_alloc+0x91/0xc0 ? bio_alloc_bioset+0x19a/0x2a0 blkdev_direct_IO+0x282/0x480 ? __io_complete_rw_common+0xc0/0xc0 ? filemap_range_has_page+0x82/0xc0 generic_file_direct_write+0x9d/0x1a0 ? inode_update_time+0x24/0x30 __generic_file_write_iter+0xbd/0x1e0 blkdev_write_iter+0xb4/0x150 ? io_import_iovec+0x8d/0x340 io_write+0xf9/0x300 io_issue_sqe+0x3c3/0x1d30 ? sysvec_reschedule_ipi+0x6c/0x80 __io_queue_sqe+0x33/0x240 ? fget+0x76/0xa0 io_submit_sqes+0xe6a/0x18d0 ? __fget_light+0xd1/0x100 __x64_sys_io_uring_enter+0x199/0x880 ? __context_tracking_enter+0x1f/0x70 ? irqentry_exit_to_user_mode+0x24/0x30 ? irqentry_exit+0x1d/0x30 ? __context_tracking_exit+0xe/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fc97c11a7be < snip > </TASK> ---[ end trace 48b2e0e67debcaeb ]--- RIP: 0010:internal_get_user_pages_fast+0x340/0x990 < snip > Kernel panic - not syncing: Fatal exception Kernel Offset: disabled | ["https://git.kernel.org/stable/c/04edfa3dc06ecfc6133a33bc7271298782dee875","https://git.kernel.org/stable/c/3ac29732a2ffa64c7de13a072b0f2848b9c11037","https://git.kernel.org/stable/c/e06d13c36ded750c72521b600293befebb4e56c5","https://git.kernel.org/stable/c/f1cf856123ceb766c49967ec79b841030fa1741f","https://git.kernel.org/stable/c/fcd0ccd836ffad73d98a66f6fea7b16f735ea920"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38560 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Ensure the copied buf is NUL terminated Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdup_user_nul instead of memdup_user. | ["https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a","https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3","https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf","https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35","https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462","https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2","https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143","https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c","https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf","https://git.kernel.org/stable/c/00b425ff0891283207d7bad607a2412225274d7a","https://git.kernel.org/stable/c/13d0cecb4626fae67c00c84d3c7851f6b62f7df3","https://git.kernel.org/stable/c/1708e3cf2488788cba5489e4f913d227de757baf","https://git.kernel.org/stable/c/204714e68015d6946279719fd464ecaf57240f35","https://git.kernel.org/stable/c/481fc0c8617304a67649027c4a44723a139a0462","https://git.kernel.org/stable/c/595a6b98deec01b6dbb20139f71edcd5fb760ec2","https://git.kernel.org/stable/c/7510fab46b1cbd1680e2a096e779aec3334b4143","https://git.kernel.org/stable/c/7d3e694c4fe30f3aba9cd5ae86fb947a54c3db5c","https://git.kernel.org/stable/c/ecb76200f5557a2886888aaa53702da1ab9e6cdf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44999 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gtp: pull network headers in gtp_dev_xmit() syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1] We must make sure the IPv4 or Ipv6 header is pulled in skb->head before accessing fields in them. Use pskb_inet_may_pull() to fix this issue. [1] BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 | ["https://git.kernel.org/stable/c/137d565ab89ce3584503b443bc9e00d44f482593","https://git.kernel.org/stable/c/1f6b62392453d8f36685d19b761307a8c5617ac1","https://git.kernel.org/stable/c/34ba4f29f3d9eb52dee37512059efb2afd7e966f","https://git.kernel.org/stable/c/3939d787139e359b77aaf9485d1e145d6713d7b9","https://git.kernel.org/stable/c/3a3be7ff9224f424e485287b54be00d2c6bd9c40","https://git.kernel.org/stable/c/3d89d0c4a1c6d4d2a755e826351b0a101dbc86f3","https://git.kernel.org/stable/c/cbb9a969fc190e85195d1b0f08038e7f6199044e","https://git.kernel.org/stable/c/f5dda8db382c5751c4e572afc7c99df7da1f83ca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46854 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dpaa: Pad packets to ETH_ZLEN When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination | ["https://git.kernel.org/stable/c/1f31f51bfc8214a6deaac2920e6342cb9d019133","https://git.kernel.org/stable/c/34fcac26216ce17886af3eb392355b459367af1a","https://git.kernel.org/stable/c/38f5db5587c0ee53546b28c50ba128253181ac83","https://git.kernel.org/stable/c/cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0","https://git.kernel.org/stable/c/cd5b9d657ecd44ad5f254c3fea3a6ab1cf0e2ef7","https://git.kernel.org/stable/c/ce8eabc912fe9b9a62be1a5c6af5ad2196e90fc2","https://git.kernel.org/stable/c/dc43a096cfe65b5c32168313846c5cd135d08f1d","https://git.kernel.org/stable/c/f43190e33224c49e1c7ebbc25923ff400d87ec00"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45026 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix error recovery leading to data corruption on ESE devices Extent Space Efficient (ESE) or thin provisioned volumes need to be formatted on demand during usual IO processing. The dasd_ese_needs_format function checks for error codes that signal the non existence of a proper track format. The check for incorrect length is to imprecise since other error cases leading to transport of insufficient data also have this flag set. This might lead to data corruption in certain error cases for example during a storage server warmstart. Fix by removing the check for incorrect length and replacing by explicitly checking for invalid track format in transport mode. Also remove the check for file protected since this is not a valid ESE handling case. | ["https://git.kernel.org/stable/c/0a228896a1b3654cd461ff654f6a64e97a9c3246","https://git.kernel.org/stable/c/19f60a55b2fda49bc4f6134a5f6356ef62ee69d8","https://git.kernel.org/stable/c/5d4a304338daf83ace2887aaacafd66fe99ed5cc","https://git.kernel.org/stable/c/7db4042336580dfd75cb5faa82c12cd51098c90b","https://git.kernel.org/stable/c/93a7e2856951680cd7fe6ebd705ac10c8a8a5efd","https://git.kernel.org/stable/c/a665e3b7ac7d5cdc26e00e3d0fc8fd490e00316a","https://git.kernel.org/stable/c/e245a18281c252c8dbc467492e09bb5d4b012118"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50230 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files. | ["https://git.kernel.org/stable/c/41e192ad2779cae0102879612dfe46726e4396aa","https://git.kernel.org/stable/c/56c6171932a7fb267ac6cb4ff8759b93ee1d0e2e","https://git.kernel.org/stable/c/64afad73e4623308d8943645e5631f2c7a2d7971","https://git.kernel.org/stable/c/994b2fa13a6c9cf3feca93090a9c337d48e3d60d","https://git.kernel.org/stable/c/aa0cee46c5d3fd9a39575a4c8a4f65f25f095b89","https://git.kernel.org/stable/c/cd0cdb51b15203fa27d4b714be83b7dfffa0b752","https://git.kernel.org/stable/c/f05dbebb8ee34882505d53d83af7d18f28a49248","https://git.kernel.org/stable/c/f2f1fa446676c21edb777e6d2bc4fa8f956fab68"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50262 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8. | ["https://git.kernel.org/stable/c/13400ac8fb80c57c2bfb12ebd35ee121ce9b4d21","https://git.kernel.org/stable/c/590976f921723d53ac199c01d5b7b73a94875e68","https://git.kernel.org/stable/c/86c8ebe02d8806dd8878d0063e8e185622ab6ea6","https://git.kernel.org/stable/c/90a6e0e1e151ef7a9282e78f54c3091de2dcc99c","https://git.kernel.org/stable/c/91afbc0eb3c90258ae378ae3c6ead3d2371e926d","https://git.kernel.org/stable/c/a035df0b98df424559fd383e8e1a268f422ea2ba","https://git.kernel.org/stable/c/c4b4f9a9ab82238cb158fa4fe61a8c0ae21a4980","https://git.kernel.org/stable/c/e8494ac079814a53fbc2258d2743e720907488ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50267 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue. | ["https://git.kernel.org/stable/c/13d6ff3ca76056d06a9d88300be2a293442ff595","https://git.kernel.org/stable/c/275258c30bbda29467216e96fb655b16bcc9992b","https://git.kernel.org/stable/c/314bdf446053e123f37543aa535197ee75f8aa97","https://git.kernel.org/stable/c/37bb5628379295c1254c113a407cab03a0f4d0b4","https://git.kernel.org/stable/c/39709ce93f5c3f9eb535efe2afea088805d1128f","https://git.kernel.org/stable/c/44fff2c16c5aafbdb70c7183dae0a415ae74705e","https://git.kernel.org/stable/c/e567fc8f7a4460e486e52c9261b1e8b9f5dc42aa","https://git.kernel.org/stable/c/e6ceb04eeb6115d872d4c4078d12f1170ed755ce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50269 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY on exit") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit(). | ["https://git.kernel.org/stable/c/498dbd9aea205db9da674994b74c7bf8e18448bd","https://git.kernel.org/stable/c/4aa77d5ea9944468e16c3eed15e858fd5de44de1","https://git.kernel.org/stable/c/63559ba8077cbadae1c92a65b73ea522bf377dd9","https://git.kernel.org/stable/c/6e2848d1c8c0139161e69ac0a94133e90e9988e8","https://git.kernel.org/stable/c/721ddad945596220c123eb6f7126729fe277ee4f","https://git.kernel.org/stable/c/8a30da5aa9609663b3e05bcc91a916537f66a4cd","https://git.kernel.org/stable/c/b08baa75b989cf779cbfa0969681f8ba2dc46569","https://git.kernel.org/stable/c/ccd811c304d2ee56189bfbc49302cb3c44361893"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53057 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOT In qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumed to be either root or ingress. This assumption is bogus since it's valid to create egress qdiscs with major handle ffff: Budimir Markovic found that for qdiscs like DRR that maintain an active class list, it will cause a UAF with a dangling class pointer. In 066a3b5b2346, the concern was to avoid iterating over the ingress qdisc since its parent is itself. The proper fix is to stop when parent TC_H_ROOT is reached because the only way to retrieve ingress is when a hierarchy which does not contain a ffff: major handle call into qdisc_lookup with TC_H_MAJ(TC_H_ROOT). In the scenario where major ffff: is an egress qdisc in any of the tree levels, the updates will also propagate to TC_H_ROOT, which then the iteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) | ["https://git.kernel.org/stable/c/05df1b1dff8f197f1c275b57ccb2ca33021df552","https://git.kernel.org/stable/c/2e95c4384438adeaa772caa560244b1a2efef816","https://git.kernel.org/stable/c/580b3189c1972aff0f993837567d36392e9d981b","https://git.kernel.org/stable/c/597cf9748c3477bf61bc35f0634129f56764ad24","https://git.kernel.org/stable/c/9995909615c3431a5304c1210face5f268d24dba","https://git.kernel.org/stable/c/ce691c814bc7a3c30c220ffb5b7422715458fd9b","https://git.kernel.org/stable/c/dbe778b08b5101df9e89bc06e0a3a7ecd2f4ef20","https://git.kernel.org/stable/c/e7f9a6f97eb067599a74f3bcb6761976b0ed303e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56784 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adding array index check to prevent memory corruption [Why & How] Array indices out of bound caused memory corruption. Adding checks to ensure that array index stays in bound. | ["https://git.kernel.org/stable/c/2c437d9a0b496168e1a1defd17b531f0a526dbe9","https://git.kernel.org/stable/c/dff526dc3e27f5484f5ba11471b9fbbe681467f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41061 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dml2/FCLKChangeSupport [Why] Potential out of bounds access in dml2_calculate_rq_and_dlg_params() because the value of out_lowest_state_idx used as an index for FCLKChangeSupport array can be greater than 1. [How] Currently dml2 core specifies identical values for all FCLKChangeSupport elements. Always use index 0 in the condition to avoid out of bounds access. | ["https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03","https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85","https://git.kernel.org/stable/c/0ad4b4a2f6357c45fbe444ead1a929a0b4017d03","https://git.kernel.org/stable/c/94166fe12543fbef122ca2d093e794ea41073a85"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46751 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info() Instead of doing a BUG_ON() handle the error by returning -EUCLEAN, aborting the transaction and logging an error message. | ["https://git.kernel.org/stable/c/18eb53a2734ff61b9a72c4fef5db7b38cb48ae16","https://git.kernel.org/stable/c/28cb13f29faf6290597b24b728dc3100c019356f","https://git.kernel.org/stable/c/3cfec712a439c5c5f5c718c5c669ee41a898f776","https://git.kernel.org/stable/c/d64807ded1b6054f066e03d8add6d920f3db9e5d","https://git.kernel.org/stable/c/ef9a8b73c8b60b27d9db4787e624a3438ffe8428"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40931 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: ensure snd_una is properly initialized on connect This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt is properly initialized on connect"). It turns out that syzkaller can trigger the retransmit after fallback and before processing any other incoming packet - so that snd_una is still left uninitialized. Address the issue explicitly initializing snd_una together with snd_nxt and write_seq. | ["https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde","https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726","https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3","https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce","https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813","https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f","https://git.kernel.org/stable/c/208cd22ef5e57f82d38ec11c1a1703f9401d6dde","https://git.kernel.org/stable/c/7b9c7fc8600b64a86e4b47b2d190bba380267726","https://git.kernel.org/stable/c/8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3","https://git.kernel.org/stable/c/ef473bf1dd7e8dd08bcc04b9e2d1bfed69a0a7ce","https://git.kernel.org/stable/c/f03c46eabb3a67bd2993e237ab5517f00a5f1813","https://git.kernel.org/stable/c/f1f0a46f8bb8890b90ab7194f0a0c8fe2a3fb57f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46689 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. | ["https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278","https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4","https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf","https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271","https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70","https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374","https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567999839d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53128 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ | ["https://git.kernel.org/stable/c/2d2b19ed4169c38dc6c61a186c5f7bdafc709691","https://git.kernel.org/stable/c/397383db9c69470642ac95beb04f2150928d663b","https://git.kernel.org/stable/c/82e813b12b10ff705f3f5d600d8492fc5248618b","https://git.kernel.org/stable/c/fbfe23012cec509dfbe09852019c4e4bb84999d0","https://git.kernel.org/stable/c/fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45009 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only decrement add_addr_accepted for MPJ req Adding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0) ... before decrementing the add_addr_accepted counter helped to find a bug when running the "remove single subflow" subtest from the mptcp_join.sh selftest. Removing a 'subflow' endpoint will first trigger a RM_ADDR, then the subflow closure. Before this patch, and upon the reception of the RM_ADDR, the other peer will then try to decrement this add_addr_accepted. That's not correct because the attached subflows have not been created upon the reception of an ADD_ADDR. A way to solve that is to decrement the counter only if the attached subflow was an MP_JOIN to a remote id that was not 0, and initiated by the host receiving the RM_ADDR. | ["https://git.kernel.org/stable/c/1c1f721375989579e46741f59523e39ec9b2a9bd","https://git.kernel.org/stable/c/2060f1efab370b496c4903b840844ecaff324c3c","https://git.kernel.org/stable/c/35b31f5549ede4070566b949781e83495906b43d","https://git.kernel.org/stable/c/85b866e4c4e63a1d7afb58f1e24273caad03d0b7","https://git.kernel.org/stable/c/d20bf2c96d7ffd171299b32f562f70e5bf5dc608"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45011 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: Check USB endpoints when probing device Ensure, as the driver probes the device, that all endpoints that the driver may attempt to access exist and are of the correct type. All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint at address 1. This is verified in xillyusb_setup_base_eps(). On top of that, a XillyUSB device may have additional Bulk OUT endpoints. The information about these endpoints' addresses is deduced from a data structure (the IDT) that the driver fetches from the device while probing it. These endpoints are checked in setup_channels(). A XillyUSB device never has more than one IN endpoint, as all data towards the host is multiplexed in this single Bulk IN endpoint. This is why setup_channels() only checks OUT endpoints. | ["https://git.kernel.org/stable/c/1371d32b95972d39c1e6e4bae8b6d0df1b573731","https://git.kernel.org/stable/c/2374bf7558de915edc6ec8cb10ec3291dfab9594","https://git.kernel.org/stable/c/25ee8b2908200fc862c0434e5ad483817d50ceda","https://git.kernel.org/stable/c/4267131278f5cc98f8db31d035d64bdbbfe18658","https://git.kernel.org/stable/c/5cff754692ad45d5086b75fef8cc3a99c30a1005"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50237 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data | ["https://git.kernel.org/stable/c/393b6bc174b0dd21bb2a36c13b36e62fc3474a23","https://git.kernel.org/stable/c/3ccf525a73d48e814634847f6d4a6150c6f0dffc","https://git.kernel.org/stable/c/78b698fbf37208ee921ee4cedea75b5d33d6ea9f","https://git.kernel.org/stable/c/8f6cd4d5bb7406656835a90e4f1a2192607f0c21","https://git.kernel.org/stable/c/b0b862aa3dbcd16b3c4715259a825f48ca540088","https://git.kernel.org/stable/c/b2bcbe5450b20641f512d6b26c6b256a5a4f847f","https://git.kernel.org/stable/c/c21efba8b5a86537ccdf43f77536bad02f82776c","https://git.kernel.org/stable/c/ee35c423042c9e04079fdee3db545135d609d6ea"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50273 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead. | ["https://git.kernel.org/stable/c/2cb1a73d1d44a1c11b0ee5eeced765dd80ec48e6","https://git.kernel.org/stable/c/2fd0948a483e9cb2d669c7199bc620a21c97673d","https://git.kernel.org/stable/c/50a3933760b427759afdd23156a7280a19357a92","https://git.kernel.org/stable/c/93c5b8decc0ef39ba84f4211d2db6da0a4aefbeb","https://git.kernel.org/stable/c/bf0b0c6d159767c0d1c21f793950d78486690ee0","https://git.kernel.org/stable/c/c24fa427fc0ae827b2a3a07f13738cbf82c3f851","https://git.kernel.org/stable/c/c9a75ec45f1111ef530ab186c2a7684d0a0c9245","https://git.kernel.org/stable/c/f04be6d68f715c1473a8422fc0460f57b5e99931"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50296 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store(). | ["https://git.kernel.org/stable/c/590a4b2d4e0b73586e88bce9b8135b593355ec09","https://git.kernel.org/stable/c/719edd9f3372ce7fb3b157647c6658672946874b","https://git.kernel.org/stable/c/76b155e14d9b182ce83d32ada2d0d7219ea8c8dd","https://git.kernel.org/stable/c/7ae4e56de7dbd0999578246a536cf52a63f4056d","https://git.kernel.org/stable/c/a0df055775f30850c0da8f7dab40d67c0fd63908","https://git.kernel.org/stable/c/b5c94e4d947d15d521e935ff10c5a22a7883dea5","https://git.kernel.org/stable/c/df3dff8ab6d79edc942464999d06fbaedf8cdd18","https://git.kernel.org/stable/c/e36482b222e00cc7aeeea772fc0cf2943590bc4d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53066 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init(). | ["https://git.kernel.org/stable/c/25ffd294fef81a7f3cd9528adf21560c04d98747","https://git.kernel.org/stable/c/8fc5ea9231af9122d227c9c13f5e578fca48d2e3","https://git.kernel.org/stable/c/9b453e8b108a5a93a6e348cf2ba4c9c138314a00","https://git.kernel.org/stable/c/9be0a21ae52b3b822d0eec4d14e909ab394f8a92","https://git.kernel.org/stable/c/bbfcd261cc068fe1cd02a4e871275074a0daa4e2","https://git.kernel.org/stable/c/dc270d7159699ad6d11decadfce9633f0f71c1db","https://git.kernel.org/stable/c/f6b2b2b981af8e7d7c62d34143acefa4e1edfe8b","https://git.kernel.org/stable/c/f749cb60a01f8391c760a1d6ecd938cadacf9549"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48953 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtc: cmos: Fix event handler registration ordering issue Because acpi_install_fixed_event_handler() enables the event automatically on success, it is incorrect to call it before the handler routine passed to it is ready to handle events. Unfortunately, the rtc-cmos driver does exactly the incorrect thing by calling cmos_wake_setup(), which passes rtc_handler() to acpi_install_fixed_event_handler(), before cmos_do_probe(), because rtc_handler() uses dev_get_drvdata() to get to the cmos object pointer and the driver data pointer is only populated in cmos_do_probe(). This leads to a NULL pointer dereference in rtc_handler() on boot if the RTC fixed event happens to be active at the init time. To address this issue, change the initialization ordering of the driver so that cmos_wake_setup() is always called after a successful cmos_do_probe() call. While at it, change cmos_pnp_probe() to call cmos_do_probe() after the initial if () statement used for computing the IRQ argument to be passed to cmos_do_probe() which is cleaner than calling it in each branch of that if () (local variable "irq" can be of type int, because it is passed to that function as an argument of type int). Note that commit 6492fed7d8c9 ("rtc: rtc-cmos: Do not check ACPI_FADT_LOW_POWER_S0") caused this issue to affect a larger number of systems, because previously it only affected systems with ACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that commit. | ["https://git.kernel.org/stable/c/0bcfccb48696aba475f046c2021f0733659ce0ef","https://git.kernel.org/stable/c/1ba745fce13d19775100eece30b0bfb8b8b10ea6","https://git.kernel.org/stable/c/4919d3eb2ec0ee364f7e3cf2d99646c1b224fae8","https://git.kernel.org/stable/c/60c6e563a843032cf6ff84b2fb732cd8754fc10d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48961 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix unbalanced fwnode reference count in mdio_device_release() There is warning report about of_node refcount leak while probing mdio device: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4 In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly. After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced. | ["https://git.kernel.org/stable/c/16854177745a5648f8ec322353b432e18460f43a","https://git.kernel.org/stable/c/a5c6de1a6656b8cc6bce7cb3d9874dd7df4968c3","https://git.kernel.org/stable/c/cb37617687f2bfa5b675df7779f869147c9002bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48975 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix memory leak in gpiochip_setup_dev() Here is a backtrace report about memory leak detected in gpiochip_setup_dev(): unreferenced object 0xffff88810b406400 (size 512): comm "python3", pid 1682, jiffies 4295346908 (age 24.090s) backtrace: kmalloc_trace device_add device_private_init at drivers/base/core.c:3361 (inlined by) device_add at drivers/base/core.c:3411 cdev_device_add gpiolib_cdev_register gpiochip_setup_dev gpiochip_add_data_with_key gcdev_register() & gcdev_unregister() would call device_add() & device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device. However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del(). Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path. Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree(). While at it, fix another subtle issue, i.e. when gc->ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It's not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev->descs variable. | ["https://git.kernel.org/stable/c/371363716398ed718e389bea8c5e9843a79dde4e","https://git.kernel.org/stable/c/6daaa84b621485fe28c401be18debf92ae8ef04a","https://git.kernel.org/stable/c/ec851b23084b3a0af8bf0f5e51d33a8d678bdc49"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49000 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in has_external_pci() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() before 'return true' to avoid reference count leak. | ["https://git.kernel.org/stable/c/10ed7655a17f6a3eaecd1293830488259ccd5723","https://git.kernel.org/stable/c/17f67414718e6aba123335a33b7d15aa594fff34","https://git.kernel.org/stable/c/afca9e19cc720bfafc75dc5ce429c185ca93f31d","https://git.kernel.org/stable/c/b6eea8b2e858a20ad58ac62dc2de90fea2413f94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49004 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: riscv: Sync efi page table's kernel mappings before switching The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic. Fix that by updating the efi kernel mappings before switching to the efi page table. | ["https://git.kernel.org/stable/c/3f105a742725a1b78766a55169f1d827732e62b8","https://git.kernel.org/stable/c/96f479383d92944406d4b3f2bc03c2f640def9f1","https://git.kernel.org/stable/c/fa7a7d185ef380546b4b1fed6f84f31dbae8cec7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49016 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mdiobus: fix unbalanced node reference count I got the following report while doing device(mscc-miim) load test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled: OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@7107009c/ethernet-phy@0 If the 'fwnode' is not an acpi node, the refcount is get in fwnode_mdiobus_phy_device_register(), but it has never been put when the device is freed in the normal path. So call fwnode_handle_put() in phy_device_release() to avoid leak. If it's an acpi node, it has never been get, but it's put in the error path, so call fwnode_handle_get() before phy_device_register() to keep get/put operation balanced. | ["https://git.kernel.org/stable/c/2708b357440427d6a9fee667eb7b8307f4625adc","https://git.kernel.org/stable/c/543d917f691ab06885ee779c862065899eaa4251","https://git.kernel.org/stable/c/cdde1560118f82498fc9e9a7c1ef7f0ef7755891"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49028 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ixgbevf: Fix resource leak in ixgbevf_init_module() ixgbevf_init_module() won't destroy the workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Add destroy_workqueue() in fail path to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak") | ["https://git.kernel.org/stable/c/7109e941099244cc876a4b3cb7a3ec79f104374a","https://git.kernel.org/stable/c/8cfa238a48f34038464b99d0b4825238c2687181","https://git.kernel.org/stable/c/c99671d4699dcf90d6939923c8fe8a8918e140b2","https://git.kernel.org/stable/c/f166c62cad798c53300b4b327e44300c73ec492d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-35501 | Low | N/A | A flaw was found in the Linux kernels implementation of audit rules, where a syscall can unexpectedly not be correctly not be logged by the audit subsystem | ["https://bugzilla.redhat.com/show_bug.cgi?id=1908577","https://bugzilla.redhat.com/show_bug.cgi?id=1908577"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4090 | High | fixed |
|
An out-of-bounds (OOB) memory write flaw was found in the NFSD in the Linux kernel. Missing sanity may lead to a write beyond bmval[bmlen-1] in nfsd4_decode_bitmap4 in fs/nfsd/nfs4xdr.c. In this flaw, a local attacker with user privilege may gain access to out-of-bounds memory, leading to a system integrity and confidentiality threat. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2025101","https://lore.kernel.org/linux-nfs/163692036074.16710.5678362976688977923.stgit%40klimt.1015granger.net/","https://security.netapp.com/advisory/ntap-20220318-0010/","https://bugzilla.redhat.com/show_bug.cgi?id=2025101","https://lore.kernel.org/linux-nfs/163692036074.16710.5678362976688977923.stgit%40klimt.1015granger.net/","https://security.netapp.com/advisory/ntap-20220318-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42161 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD [Changes from V1: - Use a default branch in the switch statement to initialize `val'.] GCC warns that `val' may be used uninitialized in the BPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val; \ [...] \ switch (__CORE_RELO(s, field, BYTE_SIZE)) { \ case 1: val = *(const unsigned char *)p; break; \ case 2: val = *(const unsigned short *)p; break; \ case 4: val = *(const unsigned int *)p; break; \ case 8: val = *(const unsigned long long *)p; break; \ } \ [...] val; \ } \ This patch adds a default entry in the switch statement that sets `val' to zero in order to avoid the warning, and random values to be used in case __builtin_preserve_field_info returns unexpected values for BPF_FIELD_BYTE_SIZE. Tested in bpf-next master. No regressions. | ["https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db","https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3","https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f","https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff","https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6","https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2","https://git.kernel.org/stable/c/009367099eb61a4fc2af44d4eb06b6b4de7de6db","https://git.kernel.org/stable/c/3364c2ed1c241989847f19cf83e3db903ce689e3","https://git.kernel.org/stable/c/7e5471b5efebc30dd0bc035cda86693a5c73d45f","https://git.kernel.org/stable/c/a21d76bd0b0d39518e9a4c19f6cf7c042a974aff","https://git.kernel.org/stable/c/b694989bb13ed5f166e633faa1eb0f21c6d261a6","https://git.kernel.org/stable/c/ff941a8449e712eaf7efca1a13bfb9afd3d99fc2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50115 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory Ignore nCR3[4:0] when loading PDPTEs from memory for nested SVM, as bits 4:0 of CR3 are ignored when PAE paging is used, and thus VMRUN doesn't enforce 32-byte alignment of nCR3. In the absolute worst case scenario, failure to ignore bits 4:0 can result in an out-of-bounds read, e.g. if the target page is at the end of a memslot, and the VMM isn't using guard pages. Per the APM: The CR3 register points to the base address of the page-directory-pointer table. The page-directory-pointer table is aligned on a 32-byte boundary, with the low 5 address bits 4:0 assumed to be 0. And the SDM's much more explicit: 4:0 Ignored Note, KVM gets this right when loading PDPTRs, it's only the nSVM flow that is broken. | ["https://git.kernel.org/stable/c/2c4adc9b192a0815fe58a62bc0709449416cc884","https://git.kernel.org/stable/c/426682afec71ea3f889b972d038238807b9443e4","https://git.kernel.org/stable/c/58cb697d80e669c56197f703e188867c8c54c494","https://git.kernel.org/stable/c/6876793907cbe19d42e9edc8c3315a21e06c32ae","https://git.kernel.org/stable/c/76ce386feb14ec9a460784fcd495d8432acce7a5","https://git.kernel.org/stable/c/f559b2e9c5c5308850544ab59396b7d53cfc67bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26771 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. | ["https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d","https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369","https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27","https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49","https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce","https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e","https://git.kernel.org/stable/c/4fe4e5adc7d29d214c59b59f61db73dec505ca3d","https://git.kernel.org/stable/c/6e2276203ac9ff10fc76917ec9813c660f627369","https://git.kernel.org/stable/c/7b24760f3a3c7ae1a176d343136b6c25174b7b27","https://git.kernel.org/stable/c/9d508c897153ae8dd79303f7f035f078139f6b49","https://git.kernel.org/stable/c/c432094aa7c9970f2fa10d2305d550d3810657ce","https://git.kernel.org/stable/c/f2a5e30d1e9a629de6179fa23923a318d5feb29e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35885 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: stop interface during shutdown The mlxbf_gige driver intermittantly encounters a NULL pointer exception while the system is shutting down via "reboot" command. The mlxbf_driver will experience an exception right after executing its shutdown() method. One example of this exception is: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000 [0000000000000070] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023 pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] sp : ffff8000080d3c10 x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58 x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008 x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128 x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7 x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101 x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404 x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080 x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20 Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002) ---[ end trace 7cc3941aa0d8e6a4 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x4ce722520000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x000005c1,a3330e5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- During system shutdown, the mlxbf_gige driver's shutdown() is always executed. However, the driver's stop() method will only execute if networking interface configuration logic within the Linux distribution has been setup to do so. If shutdown() executes but stop() does not execute, NAPI remains enabled and this can lead to an exception if NAPI is scheduled while the hardware interface has only been partially deinitialized. The networking interface managed by the mlxbf_gige driver must be properly stopped during system shutdown so that IFF_UP is cleared, the hardware interface is put into a clean state, and NAPI is fully deinitialized. | ["https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6","https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4","https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971","https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4","https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5","https://git.kernel.org/stable/c/09ba28e1cd3cf715daab1fca6e1623e22fd754a6","https://git.kernel.org/stable/c/36a1cb0371aa6f0698910ee70cb4ed3c349f4fa4","https://git.kernel.org/stable/c/63a10b530e22cc923008b5925821c26872f37971","https://git.kernel.org/stable/c/80247e0eca14ff177d565f58ecd3010f6b7910a4","https://git.kernel.org/stable/c/9783b3b0e71d704949214a8f76468f591a31f3f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50236 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [<ffffffe6e7b245dc>] __kmem_cache_alloc_node+0x1e4/0x2d8 [<ffffffe6e7adde88>] kmalloc_trace+0x48/0x110 [<ffffffe6bbd765fc>] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [<ffffffe6bbd3eed4>] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [<ffffffe6e78d5974>] process_scheduled_works+0x1ac/0x400 [<ffffffe6e78d60b8>] worker_thread+0x208/0x328 [<ffffffe6e78dc890>] kthread+0x100/0x1c0 [<ffffffe6e78166c0>] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 | ["https://git.kernel.org/stable/c/2f6f1e26ac6d2b38e2198a71f81f0ade14d6b07b","https://git.kernel.org/stable/c/4112450da7d67b59ccedc2208bae622db17dbcb8","https://git.kernel.org/stable/c/5f5a939759c79e7385946c85e62feca51a18d816","https://git.kernel.org/stable/c/6cc23898e6ba47e976050d3c080b4d2c1add3748","https://git.kernel.org/stable/c/6fc9af3df6ca7f3c94774d20f62dc7b49616026d","https://git.kernel.org/stable/c/705be2dc45c7f852e211e16bc41a916fab741983","https://git.kernel.org/stable/c/e15d84b3bba187aa372dff7c58ce1fd5cb48a076","https://git.kernel.org/stable/c/eff818238bedb9c2484c251ec46f9f160911cdc0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50287 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation. | ["https://git.kernel.org/stable/c/054931ca3cfcb8e8fa036e887d6f379942b02565","https://git.kernel.org/stable/c/0bfc6e38ee2250f0503d96f1a1de441c31d88715","https://git.kernel.org/stable/c/0cdb42ba0b28f548c1a4e86bb8489dba0d78fc21","https://git.kernel.org/stable/c/2d0f01aa602fd15a805771bdf3f4d9a9b4df7f47","https://git.kernel.org/stable/c/a749c15dccc58d9cbad9cd23bd8ab4b5fa96cf47","https://git.kernel.org/stable/c/c63c30c9d9f2c8de34b16cd2b8400240533b914e","https://git.kernel.org/stable/c/e3c36d0bde309f690ed1f9cd5f7e63b3a513f94a","https://git.kernel.org/stable/c/e6a3ea83fbe15d4818d01804e904cbb0e64e543b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48870 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: fix possible null-ptr-defer in spk_ttyio_release Run the following tests on the qemu platform: syzkaller:~# modprobe speakup_audptr input: Speakup as /devices/virtual/input/input4 initialized device: /dev/synth, node (MAJOR 10, MINOR 125) speakup 3.1.6: initialized synth name on entry is: (null) synth probe spk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned failed (errno -16), then remove the module, we will get a null-ptr-defer problem, as follow: syzkaller:~# modprobe -r speakup_audptr releasing synth audptr BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP PTI CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1 RIP: 0010:mutex_lock+0x14/0x30 Call Trace: <TASK> spk_ttyio_release+0x19/0x70 [speakup] synth_release.part.6+0xac/0xc0 [speakup] synth_remove+0x56/0x60 [speakup] __x64_sys_delete_module+0x156/0x250 ? fpregs_assert_state_consistent+0x1d/0x50 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> Modules linked in: speakup_audptr(-) speakup Dumping ftrace buffer: in_synth->dev was not initialized during modprobe, so we add check for in_synth->dev to fix this bug. | ["https://git.kernel.org/stable/c/2da67bff29ab49caafb0766e8b8383b735ff796f","https://git.kernel.org/stable/c/5abbeebd8296c2301023b8dc4b5a6c0d5229b4f5","https://git.kernel.org/stable/c/64152e05a4de3ebf59f1740a0985a6d5fba0c77b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43823 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs() If IORESOURCE_MEM is not provided in Device Tree due to any error, resource_list_first_type() will return NULL and pci_parse_request_of_pci_ranges() will just emit a warning. This will cause a NULL pointer dereference. Fix this bug by adding NULL return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0a6f1b5fe8ef8268aaa069035639968ceeea0a23","https://git.kernel.org/stable/c/a231707a91f323af1e5d9f1722055ec2fc1c7775","https://git.kernel.org/stable/c/bbba48ad67c53feea05936ea1e029dcca8057506","https://git.kernel.org/stable/c/dbcdd1863ba2ec9b76ec131df25d797709e05597"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41080 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix possible deadlock in io_register_iowq_max_workers() The io_register_iowq_max_workers() function calls io_put_sq_data(), which acquires the sqd->lock without releasing the uring_lock. Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock before acquiring sqd->lock"), this can lead to a potential deadlock situation. To resolve this issue, the uring_lock is released before calling io_put_sq_data(), and then it is re-acquired after the function call. This change ensures that the locks are acquired in the correct order, preventing the possibility of a deadlock. | ["https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf","https://git.kernel.org/stable/c/950ac86cff338ab56e2eaf611f4936ee34893b63","https://git.kernel.org/stable/c/97ed7ff58de66c544692b3c2b988f3f594348de0","https://git.kernel.org/stable/c/b17397a0a5c56e111f61cb5b77d162664dc00de9","https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca","https://git.kernel.org/stable/c/fdacd09f2ddf7a00787291f08ee48c0421e5b709","https://git.kernel.org/stable/c/73254a297c2dd094abec7c9efee32455ae875bdf","https://git.kernel.org/stable/c/b571a367502c7ef94c688ef9c7f7d69a2ce3bcca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36968 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init() l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range. Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value. divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: <TASK> l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8","https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44","https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674","https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30","https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3","https://git.kernel.org/stable/c/4d3dbaa252257d20611c3647290e6171f1bbd6c8","https://git.kernel.org/stable/c/a5b862c6a221459d54e494e88965b48dcfa6cc44","https://git.kernel.org/stable/c/ad3f7986c5a0f82b8b66a0afe1cc1f5421e1d674","https://git.kernel.org/stable/c/d2b2f7d3936dc5990549bc36ab7ac7ac37f22c30","https://git.kernel.org/stable/c/dfece2b4e3759759b2bdfac2cd6d0ee9fbf055f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49026 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: e100: Fix possible use after free in e100_xmit_prepare In e100_xmit_prepare(), if we can't map the skb, then return -ENOMEM, so e100_xmit_frame() will return NETDEV_TX_BUSY and the upper layer will resend the skb. But the skb is already freed, which will cause UAF bug when the upper layer resends the skb. Remove the harmful free. | ["https://git.kernel.org/stable/c/45605c75c52c7ae7bfe902214343aabcfe5ba0ff","https://git.kernel.org/stable/c/9fc27d22cdb9b1fcd754599d216a8992fed280cd","https://git.kernel.org/stable/c/b46f6144ab89d3d757ead940759c505091626a7d","https://git.kernel.org/stable/c/b775f37d943966f6f77dca402f5a9dedce502c25"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47691 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) - f2fs_ioc_shutdown - f2fs_do_shutdown - f2fs_stop_gc_thread - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore. | ["https://git.kernel.org/stable/c/7c339dee7eb0f8e4cadc317c595f898ef04dae30","https://git.kernel.org/stable/c/c7f114d864ac91515bb07ac271e9824a20f5ed95","https://git.kernel.org/stable/c/d79343cd66343709e409d96b2abb139a0a55ce34","https://git.kernel.org/stable/c/fc18e655b62ac6bc9f12f5de0d749b4a3fe1e812"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26930 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of the ha->vp_map pointer Coverity scan reported potential risk of double free of the pointer ha->vp_map. ha->vp_map was freed in qla2x00_mem_alloc(), and again freed in function qla2x00_mem_free(ha). Assign NULL to vp_map and kfree take care of NULL. | ["https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f","https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73","https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b","https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467","https://git.kernel.org/stable/c/825d63164a2e6bacb059a9afb5605425b485413f","https://git.kernel.org/stable/c/b7deb675d674f44e0ddbab87fee8f9f098925e73","https://git.kernel.org/stable/c/e288285d47784fdcf7c81be56df7d65c6f10c58b","https://git.kernel.org/stable/c/f14cee7a882cb79528f17a2335f53e9fd1848467"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38581 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix use-after-free issue Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c | ["https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c","https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a","https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de","https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d","https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c","https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a","https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de","https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42136 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cdrom: rearrange last_media_change check to avoid unintentional overflow When running syzkaller with the newly reintroduced signed integer wrap sanitizer we encounter this splat: [ 366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33 [ 366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long') [ 366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO [ 366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1 [ 366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 366.027518] Call Trace: [ 366.027523] <TASK> [ 366.027533] dump_stack_lvl+0x93/0xd0 [ 366.027899] handle_overflow+0x171/0x1b0 [ 366.038787] ata1.00: invalid multi_count 32 ignored [ 366.043924] cdrom_ioctl+0x2c3f/0x2d10 [ 366.063932] ? __pm_runtime_resume+0xe6/0x130 [ 366.071923] sr_block_ioctl+0x15d/0x1d0 [ 366.074624] ? __pfx_sr_block_ioctl+0x10/0x10 [ 366.077642] blkdev_ioctl+0x419/0x500 [ 366.080231] ? __pfx_blkdev_ioctl+0x10/0x10 ... Historically, the signed integer overflow sanitizer did not work in the kernel due to its interaction with `-fwrapv` but this has since been changed [1] in the newest version of Clang. It was re-enabled in the kernel with Commit 557f8c582a9ba8ab ("ubsan: Reintroduce signed overflow sanitizer"). Let's rearrange the check to not perform any arithmetic, thus not tripping the sanitizer. | ["https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b","https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3","https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c","https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf","https://git.kernel.org/stable/c/0c97527e916054acc4a46ffb02842988acb2e92b","https://git.kernel.org/stable/c/3ee21e14c8c329168a0b66bab00ecd18f5d0dee3","https://git.kernel.org/stable/c/e809bc112712da8f7e15822674c6562da6cdf24c","https://git.kernel.org/stable/c/efb905aeb44b0e99c0e6b07865b1885ae0471ebf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42147 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/debugfs - Fix debugfs uninit process issue During the zip probe process, the debugfs failure does not stop the probe. When debugfs initialization fails, jumping to the error branch will also release regs, in addition to its own rollback operation. As a result, it may be released repeatedly during the regs uninit process. Therefore, the null check needs to be added to the regs uninit process. | ["https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e","https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739","https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3","https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c","https://git.kernel.org/stable/c/7fc8d9a525b5c3f8dfa5ed50901e764d8ede7e1e","https://git.kernel.org/stable/c/8be0913389718e8d27c4f1d4537b5e1b99ed7739","https://git.kernel.org/stable/c/e0a2d2df9ba7bd6bd7e0a9b6a5e3894f7e8445b3","https://git.kernel.org/stable/c/eda60520cfe3aba9f088c68ebd5bcbca9fc6ac3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42159 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Sanitise num_phys Information is stored in mr_sas_port->phy_mask, values larger then size of this field shouldn't be allowed. | ["https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b","https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0","https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df","https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf","https://git.kernel.org/stable/c/3668651def2c1622904e58b0280ee93121f2b10b","https://git.kernel.org/stable/c/586b41060113ae43032ec6c4a16d518cef5da6e0","https://git.kernel.org/stable/c/b869ec89d2ee923d46608b76e54c006680c9b4df","https://git.kernel.org/stable/c/c8707901b53a48106d7501bdbd0350cefaefa4cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50051 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: mpc52xx: Add cancel_work_sync before module remove If we remove the module which will call mpc52xx_spi_remove it will free 'ms' through spi_unregister_controller. while the work ms->work will be used. The sequence of operations that may lead to a UAF bug. Fix it by ensuring that the work is canceled before proceeding with the cleanup in mpc52xx_spi_remove. | ["https://git.kernel.org/stable/c/373d55a47dc662e5e30d12ad5d334312f757c1f1","https://git.kernel.org/stable/c/90b72189de2cddacb26250579da0510b29a8b82b","https://git.kernel.org/stable/c/984836621aad98802d92c4a3047114cf518074c8","https://git.kernel.org/stable/c/cd5106c77d6d6828aa82449f01f4eb436d602a21","https://git.kernel.org/stable/c/d0cde3911cf24e1bcdd4caa1d1b9ef57589db5a1","https://git.kernel.org/stable/c/e0c6ce8424095c2da32a063d3fc027494c689817","https://git.kernel.org/stable/c/f65d85bc1ffd8a2c194bb2cd65e35ed3648ddd59"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56759 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when COWing tree bock and tracing is enabled When a COWing a tree block, at btrfs_cow_block(), and we have the tracepoint trace_btrfs_cow_block() enabled and preemption is also enabled (CONFIG_PREEMPT=y), we can trigger a use-after-free in the COWed extent buffer while inside the tracepoint code. This is because in some paths that call btrfs_cow_block(), such as btrfs_search_slot(), we are holding the last reference on the extent buffer @buf so btrfs_force_cow_block() drops the last reference on the @buf extent buffer when it calls free_extent_buffer_stale(buf), which schedules the release of the extent buffer with RCU. This means that if we are on a kernel with preemption, the current task may be preempted before calling trace_btrfs_cow_block() and the extent buffer already released by the time trace_btrfs_cow_block() is called, resulting in a use-after-free. Fix this by moving the trace_btrfs_cow_block() from btrfs_cow_block() to btrfs_force_cow_block() before the COWed extent buffer is freed. This also has a side effect of invoking the tracepoint in the tree defrag code, at defrag.c:btrfs_realloc_node(), since btrfs_force_cow_block() is called there, but this is fine and it was actually missing there. | ["https://git.kernel.org/stable/c/44f52bbe96dfdbe4aca3818a2534520082a07040","https://git.kernel.org/stable/c/526ff5b27f090fb15040471f892cd2c9899ce314","https://git.kernel.org/stable/c/66376f1a73cba57fd0af2631d7888605b738e499","https://git.kernel.org/stable/c/9a466b8693b9add05de99af00c7bdff8259ecf19","https://git.kernel.org/stable/c/ba5120a2fb5f23b4d39d302e181aa5d4e28a90d1","https://git.kernel.org/stable/c/c3a403d8ce36f5a809a492581de5ad17843e4701"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57896 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount During the unmount path, at close_ctree(), we first stop the cleaner kthread, using kthread_stop() which frees the associated task_struct, and then stop and destroy all the work queues. However after we stopped the cleaner we may still have a worker from the delalloc_workers queue running inode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(), which in turn tries to wake up the cleaner kthread - which was already destroyed before, resulting in a use-after-free on the task_struct. Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated--- | ["https://git.kernel.org/stable/c/1ea629e7bb2fb40555e5e01a1b5095df31287017","https://git.kernel.org/stable/c/35916b2f96505a18dc7242a115611b718d9de725","https://git.kernel.org/stable/c/63f4b594a688bf922e8691f0784679aa7af7988c","https://git.kernel.org/stable/c/a2718ed1eb8c3611b63f8933c7e68c8821fe2808","https://git.kernel.org/stable/c/d77a3a99b53d12c061c007cdc96df38825dee476","https://git.kernel.org/stable/c/f10bef73fb355e3fc85e63a50386798be68ff486"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57900 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ila: serialize calls to nf_register_net_hooks() syzbot found a race in ila_add_mapping() [1] commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner") attempted to fix a similar issue. Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands. Add a mutex to make sure at most one thread is calling nf_register_net_hooks(). [1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501 CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049 | ["https://git.kernel.org/stable/c/1638f430f8900f2375f5de45508fbe553997e190","https://git.kernel.org/stable/c/17e8fa894345e8d2c7a7642482267b275c3d4553","https://git.kernel.org/stable/c/260466b576bca0081a7d4acecc8e93687aa22d0e","https://git.kernel.org/stable/c/3d1b63cf468e446b9feaf4e4e73182b9cc82f460","https://git.kernel.org/stable/c/ad0677c37c14fa28913daea92d139644d7acf04e","https://git.kernel.org/stable/c/d3017895e393536b234cf80a83fc463c08a28137","https://git.kernel.org/stable/c/eba25e21dce7ec70e2b3f121b2f3a25a4ec43eca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46673 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: aacraid: Fix double-free on probe failure aac_probe_one() calls hardware-specific init functions through the aac_driver_ident::init pointer, all of which eventually call down to aac_init_adapter(). If aac_init_adapter() fails after allocating memory for aac_dev::queues, it frees the memory but does not clear that member. After the hardware-specific init function returns an error, aac_probe_one() goes down an error path that frees the memory pointed to by aac_dev::queues, resulting.in a double-free. | ["https://git.kernel.org/stable/c/4b540ec7c0045c2d01c4e479f34bbc8f147afa4c","https://git.kernel.org/stable/c/564e1986b00c5f05d75342f8407f75f0a17b94df","https://git.kernel.org/stable/c/60962c3d8e18e5d8dfa16df788974dd7f35bd87a","https://git.kernel.org/stable/c/85449b28ff6a89c4513115e43ddcad949b5890c9","https://git.kernel.org/stable/c/8a3995a3ffeca280a961b59f5c99843d81b15929","https://git.kernel.org/stable/c/919ddf8336f0b84c0453bac583808c9f165a85c2","https://git.kernel.org/stable/c/9e96dea7eff6f2bbcd0b42a098012fc66af9eb69","https://git.kernel.org/stable/c/d237c7d06ffddcdb5d36948c527dc01284388218"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50063 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses. | ["https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356","https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1","https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1","https://git.kernel.org/stable/c/d9a807fb7cbfad4328824186e2e4bee28f72169b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48834 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: usbtmc: Fix bug in pipe direction for control transfers The syzbot fuzzer reported a minor bug in the usbtmc driver: usb 5-1: BOGUS control dir, pipe 80001e80 doesn't match bRequestType 0 WARNING: CPU: 0 PID: 3813 at drivers/usb/core/urb.c:412 usb_submit_urb+0x13a5/0x1970 drivers/usb/core/urb.c:410 Modules linked in: CPU: 0 PID: 3813 Comm: syz-executor122 Not tainted 5.17.0-rc5-syzkaller-00306-g2293be58d6a1 #0 ... Call Trace: <TASK> usb_start_wait_urb+0x113/0x530 drivers/usb/core/message.c:58 usb_internal_control_msg drivers/usb/core/message.c:102 [inline] usb_control_msg+0x2a5/0x4b0 drivers/usb/core/message.c:153 usbtmc_ioctl_request drivers/usb/class/usbtmc.c:1947 [inline] The problem is that usbtmc_ioctl_request() uses usb_rcvctrlpipe() for all of its transfers, whether they are in or out. It's easy to fix. | ["https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e","https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952","https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016","https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7","https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b","https://git.kernel.org/stable/c/10a805334a11acd547602d6c4cf540a0f6ab5c6e","https://git.kernel.org/stable/c/5f6a2d63c68c12cf61259df7c3527a0e05dce952","https://git.kernel.org/stable/c/700a0715854c1e79a73341724ce4f5bb01abc016","https://git.kernel.org/stable/c/c69aef9db878ab277068a8cc1b4bf0cf309dc2b7","https://git.kernel.org/stable/c/e9b667a82cdcfe21d590344447d65daed52b353b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39496 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: zoned: fix use-after-free due to race with dev replace While loading a zone's info during creation of a block group, we can race with a device replace operation and then trigger a use-after-free on the device that was just replaced (source device of the replace operation). This happens because at btrfs_load_zone_info() we extract a device from the chunk map into a local variable and then use the device while not under the protection of the device replace rwsem. So if there's a device replace operation happening when we extract the device and that device is the source of the replace operation, we will trigger a use-after-free if before we finish using the device the replace operation finishes and frees the device. Fix this by enlarging the critical section under the protection of the device replace rwsem so that all uses of the device are done inside the critical section. | ["https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9","https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6","https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43","https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752","https://git.kernel.org/stable/c/0090d6e1b210551e63cf43958dc7a1ec942cdde9","https://git.kernel.org/stable/c/092571ef9a812566c8f2c9038d9c2a64c49788d6","https://git.kernel.org/stable/c/17765964703b88d8befd899f8501150bb7e07e43","https://git.kernel.org/stable/c/a0cc006f4214b87e70983c692e05bb36c59b5752"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57892 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is the dangling pointer. During the remounting process, the pointer dqi_priv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOT_SUSPENDED flag instead of setting the DQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2_get_next_id is called and only checks the quota usage flags and not the quota suspended flags. To fix this, I set dqi_priv to null when it is freed after remounting with read-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id. [akpm@linux-foundation.org: coding-style cleanups] | ["https://git.kernel.org/stable/c/2d431192486367eee03cc28d0b53b97dafcb8e63","https://git.kernel.org/stable/c/2e3d203b1adede46bbba049e497765d67865be18","https://git.kernel.org/stable/c/58f9e20e2a7602e1dd649a1ec4790077c251cb6c","https://git.kernel.org/stable/c/5f3fd772d152229d94602bca243fbb658068a597","https://git.kernel.org/stable/c/8ff6f635a08c30559ded0c110c7ce03ba7747d11","https://git.kernel.org/stable/c/ba950a02d8d23811aa1120affd3adedcfac6153d","https://git.kernel.org/stable/c/f44e6d70c100614c211703f065cad448050e4a0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53021 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_taprio: fix possible use-after-free syzbot reported a nasty crash [1] in net_tx_action() which made little sense until we got a repro. This repro installs a taprio qdisc, but providing an invalid TCA_RATE attribute. qdisc_create() has to destroy the just initialized taprio qdisc, and taprio_destroy() is called. However, the hrtimer used by taprio had already fired, therefore advance_sched() called __netif_schedule(). Then net_tx_action was trying to use a destroyed qdisc. We can not undo the __netif_schedule(), so we must wait until one cpu serviced the qdisc before we can proceed. Many thanks to Alexander Potapenko for his help. [1] BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline] BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 | ["https://git.kernel.org/stable/c/1200388a0b1c3c6fda48d4d2143db8f7e4ef5348","https://git.kernel.org/stable/c/3a415d59c1dbec9d772dbfab2d2520d98360caae","https://git.kernel.org/stable/c/c53acbf2facfdfabdc6e6984a1a38f5d38b606a1","https://git.kernel.org/stable/c/c60fe70078d6e515f424cb868d07e00411b27fbc","https://git.kernel.org/stable/c/d3b2d2820a005e43855fa71b80c4a4b194201c60"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49349 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix use-after-free in ext4_rename_dir_prepare We got issue as follows: EXT4-fs (loop0): mounted filesystem without journal. Opts: ,errors=continue ext4_get_first_dir_block: bh->b_data=0xffff88810bee6000 len=34478 ext4_get_first_dir_block: *parent_de=0xffff88810beee6ae bh->b_data=0xffff88810bee6000 ext4_rename_dir_prepare: [1] parent_de=0xffff88810beee6ae ================================================================== BUG: KASAN: use-after-free in ext4_rename_dir_prepare+0x152/0x220 Read of size 4 at addr ffff88810beee6ae by task rep/1895 CPU: 13 PID: 1895 Comm: rep Not tainted 5.10.0+ #241 Call Trace: dump_stack+0xbe/0xf9 print_address_description.constprop.0+0x1e/0x220 kasan_report.cold+0x37/0x7f ext4_rename_dir_prepare+0x152/0x220 ext4_rename+0xf44/0x1ad0 ext4_rename2+0x11c/0x170 vfs_rename+0xa84/0x1440 do_renameat2+0x683/0x8f0 __x64_sys_renameat+0x53/0x60 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f45a6fc41c9 RSP: 002b:00007ffc5a470218 EFLAGS: 00000246 ORIG_RAX: 0000000000000108 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f45a6fc41c9 RDX: 0000000000000005 RSI: 0000000020000180 RDI: 0000000000000005 RBP: 00007ffc5a470240 R08: 00007ffc5a470160 R09: 0000000020000080 R10: 00000000200001c0 R11: 0000000000000246 R12: 0000000000400bb0 R13: 00007ffc5a470320 R14: 0000000000000000 R15: 0000000000000000 The buggy address belongs to the page: page:00000000440015ce refcount:0 mapcount:0 mapping:0000000000000000 index:0x1 pfn:0x10beee flags: 0x200000000000000() raw: 0200000000000000 ffffea00043ff4c8 ffffea0004325608 0000000000000000 raw: 0000000000000001 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88810beee580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff88810beee680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88810beee700: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88810beee780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Disabling lock debugging due to kernel taint ext4_rename_dir_prepare: [2] parent_de->inode=3537895424 ext4_rename_dir_prepare: [3] dir=0xffff888124170140 ext4_rename_dir_prepare: [4] ino=2 ext4_rename_dir_prepare: ent->dir->i_ino=2 parent=-757071872 Reason is first directory entry which 'rec_len' is 34478, then will get illegal parent entry. Now, we do not check directory entry after read directory block in 'ext4_get_first_dir_block'. To solve this issue, check directory entry in 'ext4_get_first_dir_block'. [ Trigger an ext4_error() instead of just warning if the directory is missing a '.' or '..' entry. Also make sure we return an error code if the file system is corrupted. -TYT ] | ["https://git.kernel.org/stable/c/0be698ecbe4471fcad80e81ec6a05001421041b3","https://git.kernel.org/stable/c/0ff38b99fa075ddd246487a28cb9af049f4ceef1","https://git.kernel.org/stable/c/10801095224de0d0ab06ae60698680c1f883a3ae","https://git.kernel.org/stable/c/1a3a15bf6f9963d755270cbdb282863b84839195","https://git.kernel.org/stable/c/364380c00912bed9b5d99eb485018360b0ecf64f","https://git.kernel.org/stable/c/4a2bea60cf7ff957b3eda0b17750d483876a02fa","https://git.kernel.org/stable/c/97f802a652a749422dede32071d29a53cf4bd034","https://git.kernel.org/stable/c/dd887f83ea54aea5b780a84527e23ab95f777fed","https://git.kernel.org/stable/c/eaecf7ebfd5dd09038a80b14be46b844f54cfc5c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57887 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: adv7511: Fix use-after-free in adv7533_attach_dsi() The host_node pointer was assigned and freed in adv7533_parse_dt(), and later, adv7533_attach_dsi() uses the same. Fix this use-after-free issue by dropping of_node_put() in adv7533_parse_dt() and calling of_node_put() in error path of probe() and also in the remove(). | ["https://git.kernel.org/stable/c/1f49aaf55652580ae63ab83d67211fe6a55d83dc","https://git.kernel.org/stable/c/81adbd3ff21c1182e06aa02c6be0bfd9ea02d8e8","https://git.kernel.org/stable/c/acec80d9f126cd3fa764bbe3d96bc0cb5cd2b087","https://git.kernel.org/stable/c/ca9d077350fa21897de8bf64cba23b198740aab5","https://git.kernel.org/stable/c/d208571943ffddc438a7ce533d5d0b9219806242"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41073 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme: avoid double free special payload If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned. | ["https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b","https://git.kernel.org/stable/c/882574942a9be8b9d70d13462ddacc80c4b385ba","https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa","https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057","https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad","https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b","https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b","https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa","https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057","https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad","https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46782 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ila: call nf_unregister_net_hooks() sooner syzbot found an use-after-free Read in ila_nf_input [1] Issue here is that ila_xlat_exit_net() frees the rhashtable, then call nf_unregister_net_hooks(). It should be done in the reverse way, with a synchronize_rcu(). This is a good match for a pre_exit() method. [1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16 CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620 flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff) page_type: 0xbfffffff(buddy) raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000 raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini ---truncated--- | ["https://git.kernel.org/stable/c/031ae72825cef43e4650140b800ad58bf7a6a466","https://git.kernel.org/stable/c/18a5a16940464b301ea91bf5da3a324aedb347b2","https://git.kernel.org/stable/c/43d34110882b97ba1ec66cc8234b18983efb9abf","https://git.kernel.org/stable/c/47abd8adddbc0aecb8f231269ef659148d5dabe4","https://git.kernel.org/stable/c/925c18a7cff93d8a4320d652351294ff7d0ac93c","https://git.kernel.org/stable/c/93ee345ba349922834e6a9d1dadabaedcc12dce6","https://git.kernel.org/stable/c/bda4d84ac0d5421b346faee720011f58bdb99673","https://git.kernel.org/stable/c/dcaf4e2216824839d26727a15b638c6a677bd9fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46798 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix UAF for snd_soc_pcm_runtime object When using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096 kernel detects that snd_pcm_suspend_all() access a freed 'snd_soc_pcm_runtime' object when the system is suspended, which leads to a use-after-free bug: [ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270 [ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330 [ 52.047785] Call trace: [ 52.047787] dump_backtrace+0x0/0x3c0 [ 52.047794] show_stack+0x34/0x50 [ 52.047797] dump_stack_lvl+0x68/0x8c [ 52.047802] print_address_description.constprop.0+0x74/0x2c0 [ 52.047809] kasan_report+0x210/0x230 [ 52.047815] __asan_report_load1_noabort+0x3c/0x50 [ 52.047820] snd_pcm_suspend_all+0x1a8/0x270 [ 52.047824] snd_soc_suspend+0x19c/0x4e0 The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' before making any access. So we need to always set 'substream->runtime' to NULL everytime we kfree() it. | ["https://git.kernel.org/stable/c/3033ed903b4f28b5e1ab66042084fbc2c48f8624","https://git.kernel.org/stable/c/5d13afd021eb43868fe03cef6da34ad08831ad6d","https://git.kernel.org/stable/c/6a14fad8be178df6c4589667efec1789a3307b4e","https://git.kernel.org/stable/c/8ca21e7a27c66b95a4b215edc8e45e5d66679f9f","https://git.kernel.org/stable/c/993b60c7f93fa1d8ff296b58f646a867e945ae89","https://git.kernel.org/stable/c/b4a90b543d9f62d3ac34ec1ab97fc5334b048565","https://git.kernel.org/stable/c/fe5046ca91d631ec432eee3bdb1f1c49b09c8b5e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46849 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: meson: axg-card: fix 'use-after-free' Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 | ["https://git.kernel.org/stable/c/4f9a71435953f941969a4f017e2357db62d85a86","https://git.kernel.org/stable/c/5a2cc2bb81399e9ebc72560541137eb04d61dc3d","https://git.kernel.org/stable/c/7d318166bf55e9029d56997c3b134f4ac2ae2607","https://git.kernel.org/stable/c/a33145f494e6cb82f3e018662cc7c4febf271f22","https://git.kernel.org/stable/c/e1a199ec31617242e1a0ea8f312341e682d0c037","https://git.kernel.org/stable/c/e43364f578cdc2f8083abbc0cb743ea55e827c29","https://git.kernel.org/stable/c/fb0530025d502cb79d2b2801b14a9d5261833f1a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46852 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix off-by-one in CMA heap fault handler Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping. | ["https://git.kernel.org/stable/c/007180fcb6cc4a93211d4cc45fef3f5ccccd56ae","https://git.kernel.org/stable/c/79cce5e81d20fa9ad553be439d665ac3302d3c95","https://git.kernel.org/stable/c/84175dc5b2c932266a50c04e5ce342c30f817a2f","https://git.kernel.org/stable/c/e79050882b857c37634baedbdcf7c2047c24cbff","https://git.kernel.org/stable/c/ea5ff5d351b520524019f7ff7f9ce418de2dad87","https://git.kernel.org/stable/c/eb7fc8b65cea22f9038c52398c8b22849e9620ea"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26699 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr [Why] There is a potential memory access violation while iterating through array of dcn35 clks. [How] Limit iteration per array size. | ["https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc","https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb","https://git.kernel.org/stable/c/46806e59a87790760870d216f54951a5b4d545bc","https://git.kernel.org/stable/c/ca400d8e0c1c9d79c08dfb6b7f966e26c8cae7fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35829 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in rkvdec_remove in drivers/staging/media/rkvdec/rkvdec.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d","https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/","https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3228cec23b8b29215e18090c6ba635840190993d","https://lore.kernel.org/all/a4dafa22-3ee3-dbe1-fd50-fee07883ce1a%40xs4all.nl/","https://lore.kernel.org/lkml/20230307173900.1299387-1-zyytlz.wz%40163.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42311 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode() Syzbot reports uninitialized value access issue as below: loop0: detected capacity change from 0 to 64 ===================================================== BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b It missed to initialize .tz_secondswest, .cached_start and .cached_blocks fields in struct hfs_inode_info after hfs_alloc_inode(), fix it. | ["https://git.kernel.org/stable/c/10f7163bfb5f8b4e0c9c05a939f20b8540e33c65","https://git.kernel.org/stable/c/26a2ed107929a855155429b11e1293b83e6b2a8b","https://git.kernel.org/stable/c/4a52861cd76e79f1a593beb23d096523eb9732c2","https://git.kernel.org/stable/c/58d83fc160505a7009c39dec64effaac5129b971","https://git.kernel.org/stable/c/9c4e40b9b731220f9464975e49da75496e3865c4","https://git.kernel.org/stable/c/d3493d6f0dfb1ab5225b62faa77732983f2187a1","https://git.kernel.org/stable/c/d55aae5c1730d6b70d5d8eaff00113cd34772ea3","https://git.kernel.org/stable/c/f7316b2b2f11cf0c6de917beee8d3de728be24db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45025 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE copy_fd_bitmaps(new, old, count) is expected to copy the first count/BITS_PER_LONG bits from old->full_fds_bits[] and fill the rest with zeroes. What it does is copying enough words (BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest. That works fine, *if* all bits past the cutoff point are clear. Otherwise we are risking garbage from the last word we'd copied. For most of the callers that is true - expand_fdtable() has count equal to old->max_fds, so there's no open descriptors past count, let alone fully occupied words in ->open_fds[], which is what bits in ->full_fds_bits[] correspond to. The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds), which is the smallest multiple of BITS_PER_LONG that covers all opened descriptors below max_fds. In the common case (copying on fork()) max_fds is ~0U, so all opened descriptors will be below it and we are fine, by the same reasons why the call in expand_fdtable() is safe. Unfortunately, there is a case where max_fds is less than that and where we might, indeed, end up with junk in ->full_fds_bits[] - close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors. In that case we end up with observably wrong behaviour - e.g. spawn a child with CLONE_FILES, get all descriptors in range 0..127 open, then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending up with descriptor #128, despite #64 being observably not open. The minimally invasive fix would be to deal with that in dup_fd(). If this proves to add measurable overhead, we can go that way, but let's try to fix copy_fd_bitmaps() first. * new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size). * make copy_fd_bitmaps() take the bitmap size in words, rather than bits; it's 'count' argument is always a multiple of BITS_PER_LONG, so we are not losing any information, and that way we can use the same helper for all three bitmaps - compiler will see that count is a multiple of BITS_PER_LONG for the large ones, so it'll generate plain memcpy()+memset(). Reproducer added to tools/testing/selftests/core/close_range_test.c | ["https://git.kernel.org/stable/c/5053581fe5dfb09b58c65dd8462bf5dea71f41ff","https://git.kernel.org/stable/c/8cad3b2b3ab81ca55f37405ffd1315bcc2948058","https://git.kernel.org/stable/c/9a2fa1472083580b6c66bdaf291f591e1170123a","https://git.kernel.org/stable/c/c69d18f0ac7060de724511537810f10f29a27958","https://git.kernel.org/stable/c/dd72ae8b0fce9c0bbe9582b9b50820f0407f8d8a","https://git.kernel.org/stable/c/e807487a1d5fd5d941f26578ae826ca815dbfcd6","https://git.kernel.org/stable/c/ee501f827f3db02d4e599afbbc1a7f8b792d05d7","https://git.kernel.org/stable/c/fe5bf14881701119aeeda7cf685f3c226c7380df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46675 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Prevent USB core invalid event buffer address access This commit addresses an issue where the USB core could access an invalid event buffer address during runtime suspend, potentially causing SMMU faults and other memory issues in Exynos platforms. The problem arises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address. To prevent this hardware quirk on Exynos platforms, this commit ensures that the event buffer address is not cleared by software when the USB core is active during runtime suspend by checking its status before clearing the buffer address. | ["https://git.kernel.org/stable/c/111277b881def3153335acfe0d1f43e6cd83ac93","https://git.kernel.org/stable/c/14e497183df28c006603cc67fd3797a537eef7b9","https://git.kernel.org/stable/c/2189fd13c577d7881f94affc09c950a795064c4b","https://git.kernel.org/stable/c/7bb11a75dd4d3612378b90e2a4aa49bdccea28ab","https://git.kernel.org/stable/c/b72da4d89b97da71e056cc4d1429b2bc426a9c2f","https://git.kernel.org/stable/c/d2afc2bffec77316b90d530b07695e3f534df914","https://git.kernel.org/stable/c/e23f6ad8d110bf632f7471482e10b43dc174fb72","https://git.kernel.org/stable/c/eca3f543f817da87c00d1a5697b473efb548204f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26706 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix random data corruption from exception handler The current exception handler implementation, which assists when accessing user space memory, may exhibit random data corruption if the compiler decides to use a different register than the specified register %r29 (defined in ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another register, the fault handler will nevertheless store -EFAULT into %r29 and thus trash whatever this register is used for. Looking at the assembly I found that this happens sometimes in emulate_ldd(). To solve the issue, the easiest solution would be if it somehow is possible to tell the fault handler which register is used to hold the error code. Using %0 or %1 in the inline assembly is not posssible as it will show up as e.g. %r29 (with the "%r" prefix), which the GNU assembler can not convert to an integer. This patch takes another, better and more flexible approach: We extend the __ex_table (which is out of the execution path) by one 32-word. In this word we tell the compiler to insert the assembler instruction "or %r0,%r0,%reg", where %reg references the register which the compiler choosed for the error return code. In case of an access failure, the fault handler finds the __ex_table entry and can examine the opcode. The used register is encoded in the lowest 5 bits, and the fault handler can then store -EFAULT into this register. Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT config option any longer. | ["https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592","https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831","https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003","https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2","https://git.kernel.org/stable/c/23027309b099ffc4efca5477009a11dccbdae592","https://git.kernel.org/stable/c/8b1d72395635af45410b66cc4c4ab37a12c4a831","https://git.kernel.org/stable/c/ce31d79aa1f13a2345791f84935281a2c194e003","https://git.kernel.org/stable/c/fa69a8063f8b27f3c7434a0d4f464a76a62f24d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57922 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add check for granularity in dml ceil/floor helpers [Why] Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcn_bw_ functions. [How] Add check for granularity 0. (cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec) | ["https://git.kernel.org/stable/c/0881fbc4fd62e00a2b8e102725f76d10351b2ea8","https://git.kernel.org/stable/c/497471baf53bb8fd3cd1529d65d4d7f7b81f1917","https://git.kernel.org/stable/c/4f0dd09ed3001725ffd8cdc2868e71df585392fe","https://git.kernel.org/stable/c/8a9315e6f7b2d94c65a1ba476481deddb20fc3ae","https://git.kernel.org/stable/c/95793f9684e58d2aa56671b2d616b4f9f577a0a8","https://git.kernel.org/stable/c/ae9ab63a268be99a27a4720ca24f6be801744fee","https://git.kernel.org/stable/c/f3d1e4062ef251fa55ccfeca1e54a98b6818b3a1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42246 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket When using a BPF program on kernel_connect(), the call can return -EPERM. This causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing the kernel to potentially freeze up. Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN. ECONNREFUSED as error seems reasonable. For programs setting a different error can be out of reach (see handling in 4fbac77d2d09) in particular on kernels which do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -err instead of allow boolean"), thus given that it is better to simply remap for consistent behavior. UDP does handle EPERM in xs_udp_send_request(). | ["https://git.kernel.org/stable/c/02ee1976edb21a96ce8e3fd4ef563f14cc16d041","https://git.kernel.org/stable/c/5d8254e012996cee1a0f9cc920531cb7e4d9a011","https://git.kernel.org/stable/c/626dfed5fa3bfb41e0dffd796032b555b69f9cde","https://git.kernel.org/stable/c/934247ea65bc5eca8bdb7f8c0ddc15cef992a5d6","https://git.kernel.org/stable/c/bc790261218952635f846aaf90bcc0974f6f62c6","https://git.kernel.org/stable/c/d6c686c01c5f12ff8f7264e0ddf71df6cb0d4414","https://git.kernel.org/stable/c/f2431e7db0fe0daccb2f06bb0d23740affcd2fa6","https://git.kernel.org/stable/c/f388cfd913a2b96c05339a335f365795db1b36b6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0400 | High | N/A | An out-of-bounds read vulnerability was discovered in linux kernel in the smc protocol stack, causing remote dos. | ["https://access.redhat.com/security/cve/CVE-2022-0400","https://bugzilla.redhat.com/show_bug.cgi?id=2040604","https://bugzilla.redhat.com/show_bug.cgi?id=2044575","https://access.redhat.com/security/cve/CVE-2022-0400","https://bugzilla.redhat.com/show_bug.cgi?id=2040604","https://bugzilla.redhat.com/show_bug.cgi?id=2044575"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50278 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume. | ["https://git.kernel.org/stable/c/036dd6e3d2638103e0092864577ea1d091466b86","https://git.kernel.org/stable/c/13ed3624c6ef283acefa4cc42cc8ae54fd4391a4","https://git.kernel.org/stable/c/2222b0929d00e2d13732b799b63be391b5de4492","https://git.kernel.org/stable/c/483b7261b35a9d369082ab298a6670912243f0be","https://git.kernel.org/stable/c/c0ade5d98979585d4f5a93e4514c2e9a65afa08d","https://git.kernel.org/stable/c/c52ec00cb2f9bebfada22edcc0db385b910a1cdb","https://git.kernel.org/stable/c/e492f71854ce03474d49e87fd98b8df1f7cd1d2d","https://git.kernel.org/stable/c/fdef3b94dfebd57e3077a578b6e309a2bb6fa688"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50279 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 131072 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table "0 65536 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented. | ["https://git.kernel.org/stable/c/3b02c40ff10fdf83cc545850db208de855ebe22c","https://git.kernel.org/stable/c/4fa4feb873cea0e9d6ff883b37cca6f33169d8b4","https://git.kernel.org/stable/c/56507203e1b6127967ec2b51fb0b23a0d4af1334","https://git.kernel.org/stable/c/792227719725497ce10a8039803bec13f89f8910","https://git.kernel.org/stable/c/8501e38dc9e0060814c4085815fc83da3e6d43bf","https://git.kernel.org/stable/c/e57648ce325fa405fe6bbd0e6a618ced7c301a2d","https://git.kernel.org/stable/c/ee1f74925717ab36f6a091104c170639501ce818","https://git.kernel.org/stable/c/ff1dd8a04c30e8d4e2fd5c83198ca672eb6a9e7f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50301 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.] | ["https://git.kernel.org/stable/c/199c20fb7499c79557a075dc24e9a7dae7d9f1ce","https://git.kernel.org/stable/c/1e4332581cd4eed75aea77af6f66cdcdda8b49b9","https://git.kernel.org/stable/c/3e79ad156bedf2da0ab909a118d2cec6c9c22b79","https://git.kernel.org/stable/c/4a74da044ec9ec8679e6beccc4306b936b62873f","https://git.kernel.org/stable/c/4efb69a0e294ef201bcdf7ce3d6202cd0a545a5d","https://git.kernel.org/stable/c/bbad2d5b6c99db468d8f88b6ba6a56ed409b4881","https://git.kernel.org/stable/c/c3ce634ad953ce48c75c39bdfd8b711dd95f346f","https://git.kernel.org/stable/c/e0a317ad68e4ea48a0158187238c5407e4fdec8b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38540 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called with hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0. In that case, "roundup_pow_of_two(hwq_attr->aux_stride)" gets called. roundup_pow_of_two is documented as undefined for 0. Fix it in the one caller that had this combination. The undefined behavior was detected by UBSAN: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4 Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x30 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec __roundup_pow_of_two+0x25/0x35 [bnxt_re] bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re] bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re] bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re] ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? __kmalloc+0x1b6/0x4f0 ? create_qp.part.0+0x128/0x1c0 [ib_core] ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re] create_qp.part.0+0x128/0x1c0 [ib_core] ib_create_qp_kernel+0x50/0xd0 [ib_core] create_mad_qp+0x8e/0xe0 [ib_core] ? __pfx_qp_event_handler+0x10/0x10 [ib_core] ib_mad_init_device+0x2be/0x680 [ib_core] add_client_context+0x10d/0x1a0 [ib_core] enable_device_and_get+0xe0/0x1d0 [ib_core] ib_register_device+0x53c/0x630 [ib_core] ? srso_alias_return_thunk+0x5/0xfbef5 bnxt_re_probe+0xbd8/0xe50 [bnxt_re] ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re] auxiliary_bus_probe+0x49/0x80 ? driver_sysfs_add+0x57/0xc0 really_probe+0xde/0x340 ? pm_runtime_barrier+0x54/0x90 ? __pfx___driver_attach+0x10/0x10 __driver_probe_device+0x78/0x110 driver_probe_device+0x1f/0xa0 __driver_attach+0xba/0x1c0 bus_for_each_dev+0x8f/0xe0 bus_add_driver+0x146/0x220 driver_register+0x72/0xd0 __auxiliary_driver_register+0x6e/0xd0 ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] bnxt_re_mod_init+0x3e/0xff0 [bnxt_re] ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re] do_one_initcall+0x5b/0x310 do_init_module+0x90/0x250 init_module_from_file+0x86/0xc0 idempotent_init_module+0x121/0x2b0 __x64_sys_finit_module+0x5e/0xb0 do_syscall_64+0x82/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode_prepare+0x149/0x170 ? srso_alias_return_thunk+0x5/0xfbef5 ? syscall_exit_to_user_mode+0x75/0x230 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_syscall_64+0x8e/0x160 ? srso_alias_return_thunk+0x5/0xfbef5 ? __count_memcg_events+0x69/0x100 ? srso_alias_return_thunk+0x5/0xfbef5 ? count_memcg_events.constprop.0+0x1a/0x30 ? srso_alias_return_thunk+0x5/0xfbef5 ? handle_mm_fault+0x1f0/0x300 ? srso_alias_return_thunk+0x5/0xfbef5 ? do_user_addr_fault+0x34e/0x640 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f4e5132821d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0 R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60 </TASK> ---[ end trace ]--- | ["https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc","https://git.kernel.org/stable/c/66a9937187ac9b5c5ffff07b8b284483e56804d1","https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659","https://git.kernel.org/stable/c/84d2f29152184f0d72ed7c9648c4ee6927df4e59","https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753","https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98","https://git.kernel.org/stable/c/627493443f3a8458cb55cdae1da254a7001123bc","https://git.kernel.org/stable/c/78cfd17142ef70599d6409cbd709d94b3da58659","https://git.kernel.org/stable/c/8b799c00cea6fcfe5b501bbaeb228c8821acb753","https://git.kernel.org/stable/c/a658f011d89dd20cf2c7cb4760ffd79201700b98"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46859 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these. | ["https://git.kernel.org/stable/c/6821a82616f60aa72c5909b3e252ad97fb9f7e2a","https://git.kernel.org/stable/c/9291fadbd2720a869b1d2fcf82305648e2e62a16","https://git.kernel.org/stable/c/b38c19783286a71693c2194ed1b36665168c09c4","https://git.kernel.org/stable/c/b7c2f692307fe704be87ea80d7328782b33c3cef","https://git.kernel.org/stable/c/f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44949 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: parisc: fix a possible DMA corruption ARCH_DMA_MINALIGN was defined as 16 - this is too small - it may be possible that two unrelated 16-byte allocations share a cache line. If one of these allocations is written using DMA and the other is written using cached write, the value that was written with DMA may be corrupted. This commit changes ARCH_DMA_MINALIGN to be 128 on PA20 and 32 on PA1.1 - that's the largest possible cache line size. As different parisc microarchitectures have different cache line size, we define arch_slab_minalign(), cache_line_size() and dma_get_cache_alignment() so that the kernel may tune slab cache parameters dynamically, based on the detected cache line size. | ["https://git.kernel.org/stable/c/00baca74fb5879e5f9034b6156671301f500f8ee","https://git.kernel.org/stable/c/533de2f470baac40d3bf622fe631f15231a03c9f","https://git.kernel.org/stable/c/642a0b7453daff0295310774016fcb56d1f5bc7f","https://git.kernel.org/stable/c/7ae04ba36b381bffe2471eff3a93edced843240f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52760 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix slab-use-after-free in gfs2_qd_dealloc In gfs2_put_super(), whether withdrawn or not, the quota should be cleaned up by gfs2_quota_cleanup(). Otherwise, struct gfs2_sbd will be freed before gfs2_qd_dealloc (rcu callback) has run for all gfs2_quota_data objects, resulting in use-after-free. Also, gfs2_destroy_threads() and gfs2_quota_cleanup() is already called by gfs2_make_fs_ro(), so in gfs2_put_super(), after calling gfs2_make_fs_ro(), there is no need to call them again. | ["https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81","https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba","https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37","https://git.kernel.org/stable/c/08a28272faa750d4357ea2cb48d2baefd778ea81","https://git.kernel.org/stable/c/7ad4e0a4f61c57c3ca291ee010a9d677d0199fba","https://git.kernel.org/stable/c/bdcb8aa434c6d36b5c215d02a9ef07551be25a37"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41070 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group() Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group(). It looks up `stt` from tablefd, but then continues to use it after doing fdput() on the returned fd. After the fdput() the tablefd is free to be closed by another thread. The close calls kvm_spapr_tce_release() and then release_spapr_tce_table() (via call_rcu()) which frees `stt`. Although there are calls to rcu_read_lock() in kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent the UAF, because `stt` is used outside the locked regions. With an artifcial delay after the fdput() and a userspace program which triggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14 Fix it by delaying the fdput() until `stt` is no longer in use, which is effectively the entire function. To keep the patch minimal add a call to fdput() at each of the existing return paths. Future work can convert the function to goto or __cleanup style cleanup. With the fix in place the test case no longer triggers the UAF. | ["https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0","https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a","https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf","https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe","https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63","https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47","https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491","https://git.kernel.org/stable/c/4cdf6926f443c84f680213c7aafbe6f91a5fcbc0","https://git.kernel.org/stable/c/5f856023971f97fff74cfaf21b48ec320147b50a","https://git.kernel.org/stable/c/82c7a4cf14aa866f8f7f09e662b02eddc49ee0bf","https://git.kernel.org/stable/c/9975f93c760a32453d7639cf6fcf3f73b4e71ffe","https://git.kernel.org/stable/c/a986fa57fd81a1430e00b3c6cf8a325d6f894a63","https://git.kernel.org/stable/c/b26c8c85463ef27a522d24fcd05651f0bb039e47","https://git.kernel.org/stable/c/be847bb20c809de8ac124431b556f244400b0491"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42104 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: add missing check for inode numbers on directory entries Syzbot reported that mounting and unmounting a specific pattern of corrupted nilfs2 filesystem images causes a use-after-free of metadata file inodes, which triggers a kernel bug in lru_add_fn(). As Jan Kara pointed out, this is because the link count of a metadata file gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(), tries to delete that inode (ifile inode in this case). The inconsistency occurs because directories containing the inode numbers of these metadata files that should not be visible in the namespace are read without checking. Fix this issue by treating the inode numbers of these internal files as errors in the sanity check helper when reading directory folios/pages. Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer analysis. | ["https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95","https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180","https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf","https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7","https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d","https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131","https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458","https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479","https://git.kernel.org/stable/c/07c176e7acc5579c133bb923ab21316d192d0a95","https://git.kernel.org/stable/c/1b7d549ed2c1fa202c751b69423a0d3a6bd5a180","https://git.kernel.org/stable/c/265fff1a01cdc083aeaf0d934c929db5cc64aebf","https://git.kernel.org/stable/c/2f2fa9cf7c3537958a82fbe8c8595a5eb0861ad7","https://git.kernel.org/stable/c/3ab40870edb883b9633dc5cd55f5a2a11afa618d","https://git.kernel.org/stable/c/b11e8fb93ea5eefb2e4e719497ea177a58ff6131","https://git.kernel.org/stable/c/bb76c6c274683c8570ad788f79d4b875bde0e458","https://git.kernel.org/stable/c/c33c2b0d92aa1c2262d999b2598ad6fbd53bd479"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52691 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix a double-free in si_dpm_init When the allocation of adev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails, amdgpu_free_extended_power_table is called to free some fields of adev. However, when the control flow returns to si_dpm_sw_init, it goes to label dpm_failed and calls si_dpm_fini, which calls amdgpu_free_extended_power_table again and free those fields again. Thus a double-free is triggered. | ["https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706","https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334","https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30","https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4","https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0","https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a","https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2","https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9","https://git.kernel.org/stable/c/06d95c99d5a4f5accdb79464076efe62e668c706","https://git.kernel.org/stable/c/2bf47c89bbaca2bae16581ef1b28aaec0ade0334","https://git.kernel.org/stable/c/ac16667237a82e2597e329eb9bc520d1cf9dff30","https://git.kernel.org/stable/c/aeed2b4e4a70c7568d4a5eecd6a109713c0dfbf4","https://git.kernel.org/stable/c/afe9f5b871f86d58ecdc45b217b662227d7890d0","https://git.kernel.org/stable/c/ca8e2e251c65e5a712f6025e27bd9b26d16e6f4a","https://git.kernel.org/stable/c/f957a1be647f7fc65926cbf572992ec2747a93f2","https://git.kernel.org/stable/c/fb1936cb587262cd539e84b34541abb06e42b2f9","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48847 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Fix filter limit check In watch_queue_set_filter(), there are a couple of places where we check that the filter type value does not exceed what the type_filter bitmap can hold. One place calculates the number of bits by: if (tf[i].type >= sizeof(wfilter->type_filter) * 8) which is fine, but the second does: if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG) which is not. This can lead to a couple of out-of-bounds writes due to a too-large type: (1) __set_bit() on wfilter->type_filter (2) Writing more elements in wfilter->filters[] than we allocated. Fix this by just using the proper WATCH_TYPE__NR instead, which is the number of types we actually know about. The bug may cause an oops looking something like: BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740 Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611 ... Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 ... kasan_report.cold+0x7f/0x11b ... watch_queue_set_filter+0x659/0x740 ... __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Allocated by task 611: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 watch_queue_set_filter+0x23a/0x740 __x64_sys_ioctl+0x127/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88800d2c66a0 which belongs to the cache kmalloc-32 of size 32 The buggy address is located 28 bytes inside of 32-byte region [ffff88800d2c66a0, ffff88800d2c66c0) | ["https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045","https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16","https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2","https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2","https://git.kernel.org/stable/c/1b09f28f70a5046acd64138075ae3f095238b045","https://git.kernel.org/stable/c/648895da69ced90ca770fd941c3d9479a9d72c16","https://git.kernel.org/stable/c/b36588ebbcef74583824c08352e75838d6fb4ff2","https://git.kernel.org/stable/c/c993ee0f9f81caf5767a50d1faeba39a0dc82af2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48960 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hix5hd2_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. | ["https://git.kernel.org/stable/c/179499e7a240b2ef590f05eb379c810c26bbc8a4","https://git.kernel.org/stable/c/1b6360a093ab8969c91a30bb58b753282e2ced4c","https://git.kernel.org/stable/c/3a4eddd1cb023a71df4152fcc76092953e6fe95a","https://git.kernel.org/stable/c/433c07a13f59856e4585e89e86b7d4cc59348fab","https://git.kernel.org/stable/c/8067cd244cea2c332f8326842fd10158fa2cb64f","https://git.kernel.org/stable/c/93aaa4bb72e388f6a4887541fd3d18b84f1b5ddc","https://git.kernel.org/stable/c/b6307f7a2fc1c5407b6176f2af34a95214a8c262","https://git.kernel.org/stable/c/b8ce0e6f9f88a6bb49d291498377e61ea27a5387"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48962 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: Fix potential use-after-free in hisi_femac_rx() The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free. | ["https://git.kernel.org/stable/c/196e12671cb629d9f3b77b4d8bec854fc445533a","https://git.kernel.org/stable/c/296a50aa8b2982117520713edc1375777a9f8506","https://git.kernel.org/stable/c/3501da8eb6d0f5f114a09ec953c54423f6f35885","https://git.kernel.org/stable/c/4640177049549de1a43e9bc49265f0cdfce08cfd","https://git.kernel.org/stable/c/6f4798ac9c9e98f41553c4f5e6c832c8860a6942","https://git.kernel.org/stable/c/8595a2db8eb0ffcbb466eb9f4a7507a5ba06ebb9","https://git.kernel.org/stable/c/aceec8ab752428d8e151321479e82cc1a40fee2e","https://git.kernel.org/stable/c/e71a46cc8c9ad75f3bb0e4b361e81f79c0214cca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47695 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later. | ["https://git.kernel.org/stable/c/01b9be936ee8839ab9f83a7e84ee02ac6c8303c4","https://git.kernel.org/stable/c/0429a4e972082e3a2351da414b1c017daaf8aed2","https://git.kernel.org/stable/c/1c50e0265fa332c94a4a182e4efa0fc70d8fad94","https://git.kernel.org/stable/c/3e4289b29e216a55d08a89e126bc0b37cbad9f38","https://git.kernel.org/stable/c/5ac73f8191f3de41fef4f934d84d97f3aadb301f","https://git.kernel.org/stable/c/c8b7f3d9fada0d4b4b7db86bf7345cd61f1d972e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47718 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN. | ["https://git.kernel.org/stable/c/0e735a4c6137262bcefe45bb52fde7b1f5fc6c4d","https://git.kernel.org/stable/c/1b8178a2ae272256ea0dc4f940320a81003535e2","https://git.kernel.org/stable/c/7887ad11995a4142671cc49146db536f923c8568","https://git.kernel.org/stable/c/9432185540bafd42b7bfac6e6ef2f0a0fb4be447","https://git.kernel.org/stable/c/a0c1e2da652cf70825739bc12d49ea15805690bf","https://git.kernel.org/stable/c/ceaab3fb64d6a5426a3db8f87f3e5757964f2532","https://git.kernel.org/stable/c/e9a78d9417e167410d6fb83c4e908b077ad8ba6d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47730 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory. | ["https://git.kernel.org/stable/c/801d64177faaec184cee1e1aa4d8487df1364a54","https://git.kernel.org/stable/c/85e81103033324d7a271dafb584991da39554a89","https://git.kernel.org/stable/c/98d3be34c9153eceadb56de50d9f9347e88d86e4","https://git.kernel.org/stable/c/aa3e0db35a60002fb34ef0e4ad203aa59fd00203","https://git.kernel.org/stable/c/b04f06fc0243600665b3b50253869533b7938468","https://git.kernel.org/stable/c/c5f5b813e546f7fe133539c3d7a5086cc8dd2aa1","https://git.kernel.org/stable/c/f8024f12752e32ffbbf59e1c09d949f977ff743f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47748 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set. | ["https://git.kernel.org/stable/c/02e9e9366fefe461719da5d173385b6685f70319","https://git.kernel.org/stable/c/0c170b1e918b9afac25e2bbd01eaa2bfc0ece8c0","https://git.kernel.org/stable/c/7cf2fb51175cafe01df8c43fa15a06194a59c6e2","https://git.kernel.org/stable/c/927a2580208e0f9b0b47b08f1c802b7233a7ba3c","https://git.kernel.org/stable/c/ca64edd7ae93402af2596a952e0d94d545e2b9c0","https://git.kernel.org/stable/c/ec5f1b54ceb23475049ada6e7a43452cf4df88d1","https://git.kernel.org/stable/c/fae9b1776f53aab93ab345bdbf653b991aed717d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49852 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees "nport". But then we dereference "nport" on the next line which is a use after free. Re-order these lines to avoid the use after free. | ["https://git.kernel.org/stable/c/16a570f07d870a285b0c0b0d1ca4dff79e8aa5ff","https://git.kernel.org/stable/c/2e4b02fad094976763af08fec2c620f4f8edd9ae","https://git.kernel.org/stable/c/7c2908985e4ae0ea1b526b3916de9e5351650908","https://git.kernel.org/stable/c/98752fcd076a8cbc978016eae7125b4971be1eec","https://git.kernel.org/stable/c/abc71e89170ed32ecf0a5a29f31aa711e143e941","https://git.kernel.org/stable/c/baeb8628ab7f4577740f00e439d3fdf7c876b0ff"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49854 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix uaf for accessing waker_bfqq after splitting After commit 42c306ed7233 ("block, bfq: don't break merge chain in bfq_split_bfqq()"), if the current procress is the last holder of bfqq, the bfqq can be freed after bfq_split_bfqq(). Hence recored the bfqq and then access bfqq->waker_bfqq may trigger UAF. What's more, the waker_bfqq may in the merge chain of bfqq, hence just recored waker_bfqq is still not safe. Fix the problem by adding a helper bfq_waker_bfqq() to check if bfqq->waker_bfqq is in the merge chain, and current procress is the only holder. | ["https://git.kernel.org/stable/c/0780451f03bf518bc032a7c584de8f92e2d39d7f","https://git.kernel.org/stable/c/0b8bda0ff17156cd3f60944527c9d8c9f99f1583","https://git.kernel.org/stable/c/1ba0403ac6447f2d63914fb760c44a3b19c44eaf","https://git.kernel.org/stable/c/63a07379fdb6c72450cb05294461c6016b8b7726","https://git.kernel.org/stable/c/cae58d19121a70329cf971359e2518c93fec04fe","https://git.kernel.org/stable/c/de0456460f2abf921e356ed2bd8da87a376680bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49983 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes. | ["https://git.kernel.org/stable/c/1b558006d98b7b0b730027be0ee98973dd10ee0d","https://git.kernel.org/stable/c/3ff710662e8d86a63a39b334e9ca0cb10e5c14b0","https://git.kernel.org/stable/c/5c0f4cc84d3a601c99bc5e6e6eb1cbda542cce95","https://git.kernel.org/stable/c/6367d3f04c69e2b8770b8137bd800e0784b0abbc","https://git.kernel.org/stable/c/63adc9016917e6970fb0104ee5fd6770f02b2d80","https://git.kernel.org/stable/c/8c26d9e53e5fbacda0732a577e97c5a5b7882aaf","https://git.kernel.org/stable/c/a34bed978364114390162c27e50fca50791c568d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50074 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly. | ["https://git.kernel.org/stable/c/02ac3a9ef3a18b58d8f3ea2b6e46de657bf6c4f9","https://git.kernel.org/stable/c/1826b6d69bbb7f9ae8711827facbb2ad7f8d0aaa","https://git.kernel.org/stable/c/2a8b26a09c8e3ea03da1ef3cd0ef6b96e559fba6","https://git.kernel.org/stable/c/440311903231c6e6c9bcf8acb6a2885a422e00bc","https://git.kernel.org/stable/c/66029078fee00646e2e9dbb8f41ff7819f8e7569","https://git.kernel.org/stable/c/8aadef73ba3b325704ed5cfc4696a25c350182cf","https://git.kernel.org/stable/c/b0641e53e6cb937487b6cfb15772374f0ba149b3","https://git.kernel.org/stable/c/fca048f222ce9dcbde5708ba2bf81d85a4a27952"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50127 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix use-after-free in taprio_change() In 'taprio_change()', 'admin' pointer may become dangling due to sched switch / removal caused by 'advance_sched()', and critical section protected by 'q->current_entry_lock' is too small to prevent from such a scenario (which causes use-after-free detected by KASAN). Fix this by prefer 'rcu_replace_pointer()' over 'rcu_assign_pointer()' to update 'admin' immediately before an attempt to schedule freeing. | ["https://git.kernel.org/stable/c/0d4c0d2844e4eac3aed647f948fd7e60eea56a61","https://git.kernel.org/stable/c/2240f9376f20f8b6463232b4ca7292569217237f","https://git.kernel.org/stable/c/2f868ce6013548a713c431c679ef73747a66fcf3","https://git.kernel.org/stable/c/8a283a19026aaae8a773fd8061263cfa315b127f","https://git.kernel.org/stable/c/999612996df28d81f163dad530d7f8026e03aec6","https://git.kernel.org/stable/c/f504465970aebb2467da548f7c1efbbf36d0f44b","https://git.kernel.org/stable/c/fe371f084073e8672a2d7d46b335c3c060d1e301"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50131 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Consider the NULL character when validating the event length strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character. This commit checks this condition and returns failure for it. | ["https://git.kernel.org/stable/c/02874ca52df2ca2423ba6122039315ed61c25972","https://git.kernel.org/stable/c/0b6e2e22cb23105fcb171ab92f0f7516c69c8471","https://git.kernel.org/stable/c/5e3231b352725ff4a3a0095e6035af674f2d8725","https://git.kernel.org/stable/c/5fd942598ddeed9a212d1ff41f9f5b47bcc990a7","https://git.kernel.org/stable/c/a14a075a14af8d622c576145455702591bdde09d","https://git.kernel.org/stable/c/b86b0d6eea204116e4185acc35041ca4ff11a642","https://git.kernel.org/stable/c/f4ed40d1c669bba1a54407d8182acdc405683f29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52752 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free bug in cifs_debug_data_proc_show() Skip SMB sessions that are being teared down (e.g. @ses->ses_status == SES_EXITING) in cifs_debug_data_proc_show() to avoid use-after-free in @ses. This fixes the following GPF when reading from /proc/fs/cifs/DebugData while mounting and umounting [ 816.251274] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI ... [ 816.260138] Call Trace: [ 816.260329] <TASK> [ 816.260499] ? die_addr+0x36/0x90 [ 816.260762] ? exc_general_protection+0x1b3/0x410 [ 816.261126] ? asm_exc_general_protection+0x26/0x30 [ 816.261502] ? cifs_debug_tcon+0xbd/0x240 [cifs] [ 816.261878] ? cifs_debug_tcon+0xab/0x240 [cifs] [ 816.262249] cifs_debug_data_proc_show+0x516/0xdb0 [cifs] [ 816.262689] ? seq_read_iter+0x379/0x470 [ 816.262995] seq_read_iter+0x118/0x470 [ 816.263291] proc_reg_read_iter+0x53/0x90 [ 816.263596] ? srso_alias_return_thunk+0x5/0x7f [ 816.263945] vfs_read+0x201/0x350 [ 816.264211] ksys_read+0x75/0x100 [ 816.264472] do_syscall_64+0x3f/0x90 [ 816.264750] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 816.265135] RIP: 0033:0x7fd5e669d381 | ["https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a","https://git.kernel.org/stable/c/2abdf136784b7edaec7ffe0f4b461b63f9c4c4de","https://git.kernel.org/stable/c/336a066990bb3962c46daf574ace596bda9303ce","https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7","https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09","https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62","https://git.kernel.org/stable/c/0ab6f842452ce2cae04209d4671ac6289d0aef8a","https://git.kernel.org/stable/c/558817597d5fbd7af31f891b67b0fd20f0d047b7","https://git.kernel.org/stable/c/89929ea46f9cc11ba66d2c64713aa5d5dc723b09","https://git.kernel.org/stable/c/d328c09ee9f15ee5a26431f5aad7c9239fa85e62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50125 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: SCO: Fix UAF on sco_sock_timeout conn->sk maybe have been unlinked/freed while waiting for sco_conn_lock so this checks if the conn->sk is still valid by checking if it part of sco_sk_list. | ["https://git.kernel.org/stable/c/1bf4470a3939c678fb822073e9ea77a0560bc6bb","https://git.kernel.org/stable/c/74a466a15731a754bcd8b5a83c126b5122e15a45","https://git.kernel.org/stable/c/80b05fbfa998480fb3d5299d93eab946f51e9c36","https://git.kernel.org/stable/c/9ddda5d967e84796e7df1b54a55f36b4b9f21079","https://git.kernel.org/stable/c/d30803f6a972b5b9e26d1d43b583c7ec151de04b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42160 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: check validation of fault attrs in f2fs_build_fault_attr() - It missed to check validation of fault attrs in parse_options(), let's fix to add check condition in f2fs_build_fault_attr(). - Use f2fs_build_fault_attr() in __sbi_store() to clean up code. | ["https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e","https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77","https://git.kernel.org/stable/c/6e5b601706ce05d94338cad598736d96bb8096c8","https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d","https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b","https://git.kernel.org/stable/c/44958ca9e400f57bd0478115519ffc350fcee61e","https://git.kernel.org/stable/c/4ed886b187f47447ad559619c48c086f432d2b77","https://git.kernel.org/stable/c/bc84dd2c33e0c10fd90d60f0cfc0bfb504d4692d","https://git.kernel.org/stable/c/ecb641f424d6d1f055d149a15b892edcc92c504b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35828 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in renesas_usb3_remove in drivers/usb/gadget/udc/renesas_usb3.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/","https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2b947f8769be8b8181dc795fd292d3e7120f5204","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lore.kernel.org/all/20230327121700.52d881e0%40canb.auug.org.au/","https://lore.kernel.org/lkml/CAJedcCwkuznS1kSTvJXhzPoavcZDWNhNMshi-Ux0spSVRwU=RA%40mail.gmail.com/T/","https://security.netapp.com/advisory/ntap-20230803-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50208 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. | ["https://git.kernel.org/stable/c/7988bdbbb85ac85a847baf09879edcd0f70521dc","https://git.kernel.org/stable/c/87cb3b0054e53e0155b630bdf8fb714ded62565f","https://git.kernel.org/stable/c/daac56dd98e1ba814c878ac0acd482a37f2ab94b","https://git.kernel.org/stable/c/de5857fa7bcc9a496a914c7e21390be873109f26","https://git.kernel.org/stable/c/df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6","https://git.kernel.org/stable/c/ea701c1849e7250ea41a4f7493e0a5f136c1d47e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52845 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING syzbot reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue. This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names. syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue. | ["https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579","https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0","https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6","https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8","https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4","https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709","https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d","https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04","https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294","https://git.kernel.org/stable/c/19b3f72a41a8751e26bffc093bb7e1cef29ad579","https://git.kernel.org/stable/c/2199260c42e6fbc5af8adae3bf78e623407c91b0","https://git.kernel.org/stable/c/2426425d686b43adbc4f2f4a367b494f06f159d6","https://git.kernel.org/stable/c/3907b89cd17fcc23e9a80789c36856f00ece0ba8","https://git.kernel.org/stable/c/4c731e98fe4d678e87ba3e4d45d3cf0a5a193dc4","https://git.kernel.org/stable/c/560992f41c0cea44b7603bc9e6c73bffbf6b5709","https://git.kernel.org/stable/c/6744008c354bca2e4686a5b6056ee6b535d9f67d","https://git.kernel.org/stable/c/abc1582119e8c4af14cedb0db6541fd603f45a04","https://git.kernel.org/stable/c/b33d130f07f1decd756b849ab03c23d11d4dd294"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48772 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: lgdt3306a: Add a check against null-pointer-def The driver should check whether the client provides the platform_data. The following log reveals it: [ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40 [ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414 [ 29.612820] Call Trace: [ 29.613030] <TASK> [ 29.613201] dump_stack_lvl+0x56/0x6f [ 29.613496] ? kmemdup+0x30/0x40 [ 29.613754] print_report.cold+0x494/0x6b7 [ 29.614082] ? kmemdup+0x30/0x40 [ 29.614340] kasan_report+0x8a/0x190 [ 29.614628] ? kmemdup+0x30/0x40 [ 29.614888] kasan_check_range+0x14d/0x1d0 [ 29.615213] memcpy+0x20/0x60 [ 29.615454] kmemdup+0x30/0x40 [ 29.615700] lgdt3306a_probe+0x52/0x310 [ 29.616339] i2c_device_probe+0x951/0xa90 | ["https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea","https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87","https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0","https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115","https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4","https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d","https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676","https://git.kernel.org/stable/c/526238d32c3acc3d597fd8c9a34652bfe9086cea","https://git.kernel.org/stable/c/7d12e918f2994c883f41f22552a61b9310fa1e87","https://git.kernel.org/stable/c/8915dcd29a82096acacf54364a8425363782aea0","https://git.kernel.org/stable/c/8e1e00718d0d9dd83337300572561e30b9c0d115","https://git.kernel.org/stable/c/b479fd59a1f4a342b69fce34f222d93bf791dca4","https://git.kernel.org/stable/c/c1115ddbda9c930fba0fdd062e7a8873ebaf898d","https://git.kernel.org/stable/c/d082757b8359201c3864323cea4b91ea30a1e676"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39292 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: um: Add winch to winch_handlers before registering winch IRQ Registering a winch IRQ is racy, an interrupt may occur before the winch is added to the winch_handlers list. If that happens, register_winch_irq() adds to that list a winch that is scheduled to be (or has already been) freed, causing a panic later in winch_cleanup(). Avoid the race by adding the winch to the winch_handlers list before registering the IRQ, and rolling back if um_request_irq() fails. | ["https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4","https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2","https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14","https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0","https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33","https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1","https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101","https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0","https://git.kernel.org/stable/c/0c02d425a2fbe52643a5859a779db0329e7dddd4","https://git.kernel.org/stable/c/31960d991e43c8d6dc07245f19fc13398e90ead2","https://git.kernel.org/stable/c/351d1a64544944b44732f6a64ed65573b00b9e14","https://git.kernel.org/stable/c/434a06c38ee1217a8baa0dd7c37cc85d50138fb0","https://git.kernel.org/stable/c/66ea9a7c6824821476914bed21a476cd20094f33","https://git.kernel.org/stable/c/73b8e21f76c7dda4905655d2e2c17dc5a73b87f1","https://git.kernel.org/stable/c/a0fbbd36c156b9f7b2276871d499c9943dfe5101","https://git.kernel.org/stable/c/dc1ff95602ee908fcd7d8acee7a0dadb61b1a0c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41064 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/eeh: avoid possible crash when edev->pdev changes If a PCI device is removed during eeh_pe_report_edev(), edev->pdev will change and can cause a crash, hold the PCI rescan/remove lock while taking a copy of edev->pdev->bus. | ["https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1","https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b","https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff","https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274","https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3","https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd","https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5","https://git.kernel.org/stable/c/033c51dfdbb6b79ab43fb3587276fa82d0a329e1","https://git.kernel.org/stable/c/428d940a8b6b3350b282c14d3f63350bde65c48b","https://git.kernel.org/stable/c/4bc246d2d60d071314842fa448faa4ed39082aff","https://git.kernel.org/stable/c/4fad7fef847b6028475dd7b4c14fcb82b3e51274","https://git.kernel.org/stable/c/8836e1bf5838ac6c08760e0a2dd7cf6410aa7ff3","https://git.kernel.org/stable/c/a1216e62d039bf63a539bbe718536ec789a853dd","https://git.kernel.org/stable/c/f23c3d1ca9c4b2d626242a4e7e1ec1770447f7b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42145 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/core: Implement a limit on UMAD receive List The existing behavior of ib_umad, which maintains received MAD packets in an unbounded list, poses a risk of uncontrolled growth. As user-space applications extract packets from this list, the rate of extraction may not match the rate of incoming packets, leading to potential list overflow. To address this, we introduce a limit to the size of the list. After considering typical scenarios, such as OpenSM processing, which can handle approximately 100k packets per second, and the 1-second retry timeout for most packets, we set the list size limit to 200k. Packets received beyond this limit are dropped, assuming they are likely timed out by the time they are handled by user-space. Notably, packets queued on the receive list due to reasons like timed-out sends are preserved even when the list is full. | ["https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb","https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f","https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa","https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4","https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b","https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6","https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894","https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607","https://git.kernel.org/stable/c/1288cf1cceb0e6df276e182f5412370fb4169bcb","https://git.kernel.org/stable/c/62349fbf86b5e13b02721bdadf98c29afd1e7b5f","https://git.kernel.org/stable/c/63d202d948bb6d3a28cd8e8b96b160fa53e18baa","https://git.kernel.org/stable/c/a6627fba793cc75b7365d9504a0095fb2902dda4","https://git.kernel.org/stable/c/b4913702419d064ec4c4bbf7270643c95cc89a1b","https://git.kernel.org/stable/c/b8c5f635997f49c625178d1a0cb32a80ed33abe6","https://git.kernel.org/stable/c/ca0b44e20a6f3032224599f02e7c8fb49525c894","https://git.kernel.org/stable/c/d73cb8862e4d6760ccc94d3b57b9ef6271400607"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42223 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: tda10048: Fix integer overflow state->xtal_hz can be up to 16M, so it can overflow a 32 bit integer when multiplied by pll_mfactor. Create a new 64 bit variable to hold the calculations. | ["https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8","https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd","https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07","https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce","https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a","https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1","https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af","https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0","https://git.kernel.org/stable/c/1121d8a5c6ed6b8fad492e43b63b386cb6a3a9d8","https://git.kernel.org/stable/c/1663e2474e4d777187d749a5c90ae83232db32bd","https://git.kernel.org/stable/c/1aa1329a67cc214c3b7bd2a14d1301a795760b07","https://git.kernel.org/stable/c/5c72587d024f087aecec0221eaff2fe850d856ce","https://git.kernel.org/stable/c/8167e4d7dc086d4f7ca7897dcff3827e4d22c99a","https://git.kernel.org/stable/c/8ac224e9371dc3c4eb666033e6b42d05cf5184a1","https://git.kernel.org/stable/c/bd5620439959a7e02012588c724c6ff5143b80af","https://git.kernel.org/stable/c/e1ba22618758e95e09c9fd30c69ccce38edf94c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46737 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix kernel crash if commands allocation fails If the commands allocation fails in nvmet_tcp_alloc_cmds() the kernel crashes in nvmet_tcp_release_queue_work() because of a NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Fix the bug by setting queue->nr_cmds to zero in case nvmet_tcp_alloc_cmd() fails. | ["https://git.kernel.org/stable/c/03e1fd0327fa5e2174567f5fe9290fe21d21b8f4","https://git.kernel.org/stable/c/489f2913a63f528cfe3f21722583fb981967ecda","https://git.kernel.org/stable/c/50632b877ce55356f5d276b9add289b1e7ddc683","https://git.kernel.org/stable/c/5572a55a6f830ee3f3a994b6b962a5c327d28cb3","https://git.kernel.org/stable/c/6c04d1e3ab22cc5394ef656429638a5947f87244","https://git.kernel.org/stable/c/7957c731fc2b23312f8935812dee5a0b14b04e2d","https://git.kernel.org/stable/c/91dad30c5607e62864f888e735d0965567827bdf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52698 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: calipso: fix memory leak in netlbl_calipso_add_pass() If IPv6 support is disabled at boot (ipv6.disable=1), the calipso_init() -> netlbl_calipso_ops_register() function isn't called, and the netlbl_calipso_ops_get() function always returns NULL. In this case, the netlbl_calipso_add_pass() function allocates memory for the doi_def variable but doesn't free it with the calipso_doi_free(). BUG: memory leak unreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6 Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller [PM: merged via the LSM tree at Jakub Kicinski request] | ["https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149","https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53","https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031","https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01","https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da","https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded","https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99","https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c","https://git.kernel.org/stable/c/321b3a5592c8a9d6b654c7c64833ea67dbb33149","https://git.kernel.org/stable/c/36e19f84634aaa94f543fedc0a07588949638d53","https://git.kernel.org/stable/c/408bbd1e1746fe33e51f4c81c2febd7d3841d031","https://git.kernel.org/stable/c/44a88650ba55e6a7f2ec485d2c2413ba7e216f01","https://git.kernel.org/stable/c/9a8f811a146aa2a0230f8edb2e9f4b6609aab8da","https://git.kernel.org/stable/c/a4529a08d3704c17ea9c7277d180e46b99250ded","https://git.kernel.org/stable/c/ec4e9d630a64df500641892f4e259e8149594a99","https://git.kernel.org/stable/c/f14d36e6e97fe935a20e0ceb159c100f90b6627c","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52855 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue(): spin_lock_irqsave(&hsotg->lock, flags); ... if (!urb->hcpriv) { dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n"); goto out; } rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv ... out: spin_unlock_irqrestore(&hsotg->lock, flags); When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are concurrently executed, the NULL check of "urb->hcpriv" can be executed before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL pointer dereference. This possible bug is found by an experimental static analysis tool developed by myself. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. The above possible bug is reported, when my tool analyzes the source code of Linux 6.5. To fix this possible bug, "urb->hcpriv = NULL" should be executed with holding the lock "hsotg->lock". After using this patch, my tool never reports the possible bug, with the kernelconfiguration allyesconfig for x86_64. Because I have no associated hardware, I cannot test the patch in runtime testing, and just verify it according to the code logic. | ["https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72","https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d","https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e","https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790","https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90","https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6","https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6","https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001","https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d","https://git.kernel.org/stable/c/14c9ec34e8118fbffd7f5431814d767726323e72","https://git.kernel.org/stable/c/3e851a77a13ce944d703721793f49ee82622986d","https://git.kernel.org/stable/c/64c47749fc7507ed732e155c958253968c1d275e","https://git.kernel.org/stable/c/6b21a22728852d020a6658d39cd7bb7e14b07790","https://git.kernel.org/stable/c/a7bee9598afb38004841a41dd8fe68c1faff4e90","https://git.kernel.org/stable/c/bdb3dd4096302d6b87441fdc528439f171b04be6","https://git.kernel.org/stable/c/ef307bc6ef04e8c1ea843231db58e3afaafa9fa6","https://git.kernel.org/stable/c/fcaafb574fc88a52dce817f039f7ff2f9da38001","https://git.kernel.org/stable/c/fed492aa6493a91a77ebd51da6fb939c98d94a0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46807 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu: Check tbo resource pointer Validate tbo resource pointer, skip if NULL | ["https://git.kernel.org/stable/c/2be1eb6304d9623ba21dd6f3e68ffb753a759635","https://git.kernel.org/stable/c/4dfec5f5501a27e0a0da00e136d65ef9011ded4c","https://git.kernel.org/stable/c/6cd2b872643bb29bba01a8ac739138db7bd79007","https://git.kernel.org/stable/c/e55e3904ffeaff81715256a711b1a61f4ad5258a","https://git.kernel.org/stable/c/e8765364d4f3aaf88c7abe0a4fc99089d059ab49"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46810 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: tc358767: Check if fully initialized before signalling HPD event via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference. | ["https://git.kernel.org/stable/c/162e48cb1d84c2c966b649b8ac5c9d4f75f6d44f","https://git.kernel.org/stable/c/1fb13693953737783b424aa4712f0a27a9eaf5a8","https://git.kernel.org/stable/c/9d567126474e68f959b2c2543c375f3bb32e948a","https://git.kernel.org/stable/c/adc5674c23b8191e596ed0dbaa9600265ac896a8","https://git.kernel.org/stable/c/e1b121f21bbc56a6ae035aa5b77daac62bfb9be5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48997 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: char: tpm: Protect tpm_pm_suspend with locks Currently tpm transactions are executed unconditionally in tpm_pm_suspend() function, which may lead to races with other tpm accessors in the system. Specifically, the hw_random tpm driver makes use of tpm_get_random(), and this function is called in a loop from a kthread, which means it's not frozen alongside userspace, and so can race with the work done during system suspend: tpm tpm0: tpm_transmit: tpm_recv: error -52 tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Call Trace: tpm_tis_status.cold+0x19/0x20 tpm_transmit+0x13b/0x390 tpm_transmit_cmd+0x20/0x80 tpm1_pm_suspend+0xa6/0x110 tpm_pm_suspend+0x53/0x80 __pnp_bus_suspend+0x35/0xe0 __device_suspend+0x10f/0x350 Fix this by calling tpm_try_get_ops(), which itself is a wrapper around tpm_chip_start(), but takes the appropriate mutex. [Jason: reworked commit message, added metadata] | ["https://git.kernel.org/stable/c/23393c6461422df5bf8084a086ada9a7e17dc2ba","https://git.kernel.org/stable/c/25b78bf98b07ff5aceb9b1e24f72ec0236c5c053","https://git.kernel.org/stable/c/4e0d6c687c925e27fd4bc78a2721d10acf5614d6","https://git.kernel.org/stable/c/571b6bbbf54d835ea6120f65575cb55cd767e603","https://git.kernel.org/stable/c/d699373ac5f3545243d3c73a1ccab77fdef8cec6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-26607 | High | fixed |
|
In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c. | ["https://bugzilla.suse.com/show_bug.cgi?id=1208703","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075","https://lkml.org/lkml/2023/2/21/1353","https://security.netapp.com/advisory/ntap-20230316-0010/","https://bugzilla.suse.com/show_bug.cgi?id=1208703","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=36a4d82dddbbd421d2b8e79e1cab68c8126d5075","https://lkml.org/lkml/2023/2/21/1353","https://security.netapp.com/advisory/ntap-20230316-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57906 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ti-ads8688: fix information leak in triggered buffer The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values. Initialize the array to zero before using it to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/1c80a0985a9a14f33dbf63cd703ca010f094f878","https://git.kernel.org/stable/c/2a7377ccfd940cd6e9201756aff1e7852c266e69","https://git.kernel.org/stable/c/3bf8d1e87939b8a19c9b738564fddf5b73322f2f","https://git.kernel.org/stable/c/455df95eb8f24a37abc549d6738fc8ee07eb623b","https://git.kernel.org/stable/c/485570ed82b7a6bb109fa1d0a79998e21f7f4c73","https://git.kernel.org/stable/c/aae96738006840533cf147ffd5f41830987f21c5","https://git.kernel.org/stable/c/ebe2672bc42a0dfe31bb539f8ce79d024aa7e46d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57907 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: rockchip_saradc: fix information leak in triggered buffer The 'data' local struct is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values. Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/38724591364e1e3b278b4053f102b49ea06ee17c","https://git.kernel.org/stable/c/5a95fbbecec7a34bbad5dcc3156700b8711d53c4","https://git.kernel.org/stable/c/64b79afdca7b27a768c7d3716b7f4deb1d6b955c","https://git.kernel.org/stable/c/7a07fb80ea886e9134284a27d0155cca7649e293","https://git.kernel.org/stable/c/8193941bc4fe7247ff13233f328aea709f574554","https://git.kernel.org/stable/c/85a9c98a5e0f22d911b00077d751e34fff1401aa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57908 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: imu: kmx61: fix information leak in triggered buffer The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values. Initialize the array to zero before using it to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/0871eb8d700b33dd7fa86c80630d62ddaef58c2c","https://git.kernel.org/stable/c/565814cbbaa674d2901428796801de49a611e59d","https://git.kernel.org/stable/c/6985ba4467e4b15b809043fa7740d1fb23a1897b","https://git.kernel.org/stable/c/6ae053113f6a226a2303caa4936a4c37f3bfff7b","https://git.kernel.org/stable/c/a07f698084412a3ef5e950fcac1d6b0f53289efd","https://git.kernel.org/stable/c/a386d9d2dc6635f2ec210b8199cfb3acf4d31305","https://git.kernel.org/stable/c/cde312e257b59ecaa0fad3af9ec7e2370bb24639"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57910 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: light: vcnl4035: fix information leak in triggered buffer The 'buffer' local array is used to push data to userspace from a triggered buffer, but it does not set an initial value for the single data element, which is an u16 aligned to 8 bytes. That leaves at least 4 bytes uninitialized even after writing an integer value with regmap_read(). Initialize the array to zero before using it to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/13e56229fc81051a42731046e200493c4a7c28ff","https://git.kernel.org/stable/c/47b43e53c0a0edf5578d5d12f5fc71c019649279","https://git.kernel.org/stable/c/47d245be86492974db3aeb048609542167f56518","https://git.kernel.org/stable/c/a15ea87d4337479c9446b5d71616f4668337afed","https://git.kernel.org/stable/c/b0e9c11c762e4286732d80e66c08c2cb3157b06b","https://git.kernel.org/stable/c/cb488706cdec0d6d13f2895bcdf0c32b283a7cc7","https://git.kernel.org/stable/c/f6fb1c59776b4263634c472a5be8204c906ffc2c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57911 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer The 'data' array is allocated via kmalloc() and it is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iio_for_each_active_channel() to assign new values. Use kzalloc for the memory allocation to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/006073761888a632c5d6f93e47c41760fa627f77","https://git.kernel.org/stable/c/03fa47621bf8fcbf5994c5716021527853f9af3d","https://git.kernel.org/stable/c/333be433ee908a53f283beb95585dfc14c8ffb46","https://git.kernel.org/stable/c/74058395b2c63c8a438cf199d09094b640f8c7f4","https://git.kernel.org/stable/c/b0642d9c871aea1f28eb02cd84d60434df594f67","https://git.kernel.org/stable/c/e1c1e8c05010103c9c9ea3e9c4304b0b7e2c8e4a","https://git.kernel.org/stable/c/ea703cda36da0dacb9a2fd876370003197d8a019"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57912 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: pressure: zpa2326: fix information leak in triggered buffer The 'sample' local struct is used to push data to user space from a triggered buffer, but it has a hole between the temperature and the timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp). This hole is never initialized. Initialize the struct to zero before using it to avoid pushing uninitialized information to userspace. | ["https://git.kernel.org/stable/c/6007d10c5262f6f71479627c1216899ea7f09073","https://git.kernel.org/stable/c/64a989aa7475b8e76e69b9ec86819ea293e53bab","https://git.kernel.org/stable/c/9629ff1a86823269b12fb1ba9ca4efa945906287","https://git.kernel.org/stable/c/979a0db76ceda8fe1f2f85a116bfe97620ebbadf","https://git.kernel.org/stable/c/b7849f62e61242e0e02c776e1109eb81e59c567c","https://git.kernel.org/stable/c/d25f1fc273670271412a52a1efbdaf5dcf274ed8","https://git.kernel.org/stable/c/fefb88a4da961a0b9c2473cbdcfce1a942fcfa9a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42094 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/iucv: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | ["https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53","https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d","https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959","https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756","https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a","https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71","https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9","https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae","https://git.kernel.org/stable/c/0af718a690acc089aa1bbb95a93df833d864ef53","https://git.kernel.org/stable/c/2b085521be5292016097b5e7ca81b26be3f7098d","https://git.kernel.org/stable/c/2d090c7f7be3b26fcb80ac04d08a4a8062b1d959","https://git.kernel.org/stable/c/724e7965af054079242b8d6f7e50ee226730a756","https://git.kernel.org/stable/c/842afb47d84536fc976fece8fb6c54bea711ad1a","https://git.kernel.org/stable/c/9dadab0db7d904413ea1cdaa13f127da05c31e71","https://git.kernel.org/stable/c/be4e1304419c99a164b4c0e101c7c2a756b635b9","https://git.kernel.org/stable/c/d85ca8179a54ff8cf1e1f8c3c9e3799831319bae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38597 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: eth: sungem: remove .ndo_poll_controller to avoid deadlocks Erhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly. | ["https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6","https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b","https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937","https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4","https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f","https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce","https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289","https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6","https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b","https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937","https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4","https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f","https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce","https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39476 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"") However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d(). Current implementation in raid5d() has a weird dependence: 1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared; This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfig_mutex', and md_check_recovery() can't update super_block, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfig_mutex' is released. Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MD_SB_CHANGE_PENDING is still set after md_check_recovery(), daemon thread will be woken up when 'reconfig_mutex' is released. Meanwhile, the hang problem will be fixed as well. | ["https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a","https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa","https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b","https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4","https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787","https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347","https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447","https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7","https://git.kernel.org/stable/c/098d54934814dd876963abfe751c3b1cf7fbe56a","https://git.kernel.org/stable/c/151f66bb618d1fd0eeb84acb61b4a9fa5d8bb0fa","https://git.kernel.org/stable/c/3f8d5e802d4cedd445f9a89be8c3fd2d0e99024b","https://git.kernel.org/stable/c/634ba3c97ec413cb10681c7b196db43ee461ecf4","https://git.kernel.org/stable/c/aa64464c8f4d2ab92f6d0b959a1e0767b829d787","https://git.kernel.org/stable/c/b32aa95843cac6b12c2c014d40fca18aef24a347","https://git.kernel.org/stable/c/cd2538e5af495b3c747e503db346470fc1ffc447","https://git.kernel.org/stable/c/e332a12f65d8fed8cf63bedb4e9317bb872b9ac7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41098 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: Fix null pointer dereference on error If the ata_port_alloc() call in ata_host_alloc() fails, ata_host_release() will get called. However, the code in ata_host_release() tries to free ata_port struct members unconditionally, which can lead to the following: BUG: unable to handle page fault for address: 0000000000003990 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata] Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41 RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246 RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0 RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68 R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004 R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006 FS: 00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? ata_host_release.cold+0x2f/0x6e [libata] ? ata_host_release.cold+0x2f/0x6e [libata] release_nodes+0x35/0xb0 devres_release_group+0x113/0x140 ata_host_alloc+0xed/0x120 [libata] ata_host_alloc_pinfo+0x14/0xa0 [libata] ahci_init_one+0x6c9/0xd20 [ahci] Do not access ata_port struct members unconditionally. | ["https://git.kernel.org/stable/c/0f0d37c154bb108730c90a91aa31e3170e827962","https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28","https://git.kernel.org/stable/c/221e3b1297e74fdec32d0f572f4dcb2260a0a2af","https://git.kernel.org/stable/c/56e62977eaaae3eb7122ee2cf9b720b6703114a9","https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e","https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8","https://git.kernel.org/stable/c/d9c4df80b1b009de1eb77c07e3bb4d45bd212aa5","https://git.kernel.org/stable/c/e83405e75d90694ee6a5d898f7f0473ac2686054","https://git.kernel.org/stable/c/119c97ace2a9ffcf4dc09a23bb057d6c281aff28","https://git.kernel.org/stable/c/5d92c7c566dc76d96e0e19e481d926bbe6631c1e","https://git.kernel.org/stable/c/8a8ff7e3b736a70d7b7c8764cbcd2724d4079ec8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46676 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Add poll mod list filling check In case of im_protocols value is 1 and tm_protocols value is 0 this combination successfully passes the check 'if (!im_protocols && !tm_protocols)' in the nfc_start_poll(). But then after pn533_poll_create_mod_list() call in pn533_start_poll() poll mod list will remain empty and dev->poll_mod_count will remain 0 which lead to division by zero. Normally no im protocol has value 1 in the mask, so this combination is not expected by driver. But these protocol values actually come from userspace via Netlink interface (NFC_CMD_START_POLL operation). So a broken or malicious program may pass a message containing a "bad" combination of protocol parameter values so that dev->poll_mod_count is not incremented inside pn533_poll_create_mod_list(), thus leading to division by zero. Call trace looks like: nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll() Add poll mod list filling check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/56ad559cf6d87f250a8d203b555dfc3716afa946","https://git.kernel.org/stable/c/64513d0e546a1f19e390f7e5eba3872bfcbdacf5","https://git.kernel.org/stable/c/7535db0624a2dede374c42040808ad9a9101d723","https://git.kernel.org/stable/c/7ecd3dd4f8eecd3309432156ccfe24768e009ec4","https://git.kernel.org/stable/c/8ddaea033de051ed61b39f6b69ad54a411172b33","https://git.kernel.org/stable/c/c5e05237444f32f6cfe5d907603a232c77a08b31","https://git.kernel.org/stable/c/febccb39255f9df35527b88c953b2e0deae50e53"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47665 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL. | ["https://git.kernel.org/stable/c/2666085335bdfedf90d91f4071490ad3980be785","https://git.kernel.org/stable/c/5a022269abb22809f2a174b90f200fc4b9526058","https://git.kernel.org/stable/c/8a2be2f1db268ec735419e53ef04ca039fc027dc","https://git.kernel.org/stable/c/cacb76df247a7cd842ff29755a523b1cba6c0508","https://git.kernel.org/stable/c/e2d14bfda9eb5393f8a17008afe2aa7fe0a29815"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47673 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: pause TCM when the firmware is stopped Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30 | ["https://git.kernel.org/stable/c/0668ebc8c2282ca1e7eb96092a347baefffb5fe7","https://git.kernel.org/stable/c/2c61b561baf92a2860c76c2302a62169e22c21cc","https://git.kernel.org/stable/c/55086c97a55d781b04a2667401c75ffde190135c","https://git.kernel.org/stable/c/5948a191906b54e10f02f6b7a7670243a39f99f4","https://git.kernel.org/stable/c/a15df5f37fa3a8b7a8ec7a339d1e897bc524e28f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49905 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252) | ["https://git.kernel.org/stable/c/75839e2365b666ff4e1b9047e442cab138eac4f6","https://git.kernel.org/stable/c/9132882eaae4d21d2fc5843b3308379a481ebdf0","https://git.kernel.org/stable/c/bd0e24e5e608ccb9fdda300bb974496d6d8cf57d","https://git.kernel.org/stable/c/cd9e9e0852d501f169aa3bb34e4b413d2eb48c37","https://git.kernel.org/stable/c/e4e26cbe34d7c1c1db5fb7b3101573c29866439f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49912 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774) | ["https://git.kernel.org/stable/c/0ffd9fb03bbc99ed1eb5dc989d5c7da2faac0659","https://git.kernel.org/stable/c/4778982c73d6c9f3fdbdbc6b6c8aa18df98251af","https://git.kernel.org/stable/c/8141f21b941710ecebe49220b69822cab3abd23d","https://git.kernel.org/stable/c/c4b699b93496c423b0e5b584d4eb4ab849313bcf","https://git.kernel.org/stable/c/ec6c32b58e6c4e87760e797c525e99a460c82bcb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50062 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref. | ["https://git.kernel.org/stable/c/394b2f4d5e014820455af3eb5859eb328eaafcfd","https://git.kernel.org/stable/c/b5d4076664465487a9a3d226756995b12fb73d71","https://git.kernel.org/stable/c/b720792d7e8515bc695752e0ed5884e2ea34d12a","https://git.kernel.org/stable/c/ccb8e44ae3e2391235f80ffc6be59bec6b889ead","https://git.kernel.org/stable/c/d0e62bf7b575fbfe591f6f570e7595dd60a2f5eb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43900 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: xc2028: avoid use-after-free in load_firmware_cb() syzkaller reported use-after-free in load_firmware_cb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free. The process is as follows: task-6504 worker_thread tuner_probe <= alloc dvb_frontend [2] ... request_firmware_nowait <= create a worker ... tuner_remove <= free dvb_frontend ... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freed To fix the issue, check the dvd_frontend in load_firmware_cb(), if it is null, report a warning and just return. [1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== [2] Actually, it is allocated for struct tuner, and dvb_frontend is inside. | ["https://git.kernel.org/stable/c/208deb6d8c3cb8c3acb1f41eb31cf68ea08726d5","https://git.kernel.org/stable/c/68594cec291ff9523b9feb3f43fd853dcddd1f60","https://git.kernel.org/stable/c/850304152d367f104d21c77cfbcc05806504218b","https://git.kernel.org/stable/c/ef517bdfc01818419f7bd426969a0c86b14f3e0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49950 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: kasan_save_stack+0x33/0x60 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 | ["https://git.kernel.org/stable/c/333b4fd11e89b29c84c269123f871883a30be586","https://git.kernel.org/stable/c/686e05c9dbd68766c6bda5f31f7e077f36a7fb29","https://git.kernel.org/stable/c/78d30ce16fdf9c301bcd8b83ce613cea079cea83","https://git.kernel.org/stable/c/a1c6174e23df10b8e5770e82d63bc6e2118a3dc7","https://git.kernel.org/stable/c/b22346eec479a30bfa4a02ad2c551b54809694d0","https://git.kernel.org/stable/c/b90907696c30172b809aa3dd2f0caffae761e4c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39494 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ima: Fix use-after-free on a dentry's dname.name ->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead. | ["https://git.kernel.org/stable/c/0b31e28fbd773aefb6164687e0767319b8199829","https://git.kernel.org/stable/c/480afcbeb7aaaa22677d3dd48ec590b441eaac1a","https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4","https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c","https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de","https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c","https://git.kernel.org/stable/c/edf287bc610b18d7a9c0c0c1cb2e97b9348c71bb","https://git.kernel.org/stable/c/7fb374981e31c193b1152ed8d3b0a95b671330d4","https://git.kernel.org/stable/c/a78a6f0da57d058e2009e9958fdcef66f165208c","https://git.kernel.org/stable/c/be84f32bb2c981ca670922e047cdde1488b233de","https://git.kernel.org/stable/c/dd431c3ac1fc34a9268580dd59ad3e3c76b32a8c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52757 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential deadlock when releasing mids All release_mid() callers seem to hold a reference of @mid so there is no need to call kref_put(&mid->refcount, __release_mid) under @server->mid_lock spinlock. If they don't, then an use-after-free bug would have occurred anyways. By getting rid of such spinlock also fixes a potential deadlock as shown below CPU 0 CPU 1 ------------------------------------------------------------------ cifs_demultiplex_thread() cifs_debug_data_proc_show() release_mid() spin_lock(&server->mid_lock); spin_lock(&cifs_tcp_ses_lock) spin_lock(&server->mid_lock) __release_mid() smb2_find_smb_tcon() spin_lock(&cifs_tcp_ses_lock) *deadlock* | ["https://git.kernel.org/stable/c/99f476e27aad5964ab13777d84fda67d1356dec1","https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29","https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf","https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26","https://git.kernel.org/stable/c/ce49569079a9d4cad26c0f1d4653382fd9a5ca7a","https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7","https://git.kernel.org/stable/c/9eb44db68c5b7f5aa22b8fc7de74a3e2e08d1f29","https://git.kernel.org/stable/c/b9bb9607b1fc12fca51f5632da25b36975f599bf","https://git.kernel.org/stable/c/c1a5962f1462b64fe7b69f20a4b6af8067bc2d26","https://git.kernel.org/stable/c/e6322fd177c6885a21dd4609dc5e5c973d1a2eb7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48837 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: prevent integer overflow in rndis_set_response() If "BufOffset" is very large the "BufOffset + 8" operation can have an integer overflow. | ["https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7","https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e","https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65","https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c","https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa","https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b","https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90","https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0","https://git.kernel.org/stable/c/138d4f739b35dfb40438a0d5d7054965763bfbe7","https://git.kernel.org/stable/c/21829376268397f9fd2c35cfa9135937b6aa3a1e","https://git.kernel.org/stable/c/28bc0267399f42f987916a7174e2e32f0833cc65","https://git.kernel.org/stable/c/56b38e3ca4064041d93c1ca18828c8cedad2e16c","https://git.kernel.org/stable/c/65f3324f4b6fed78b8761c3b74615ecf0ffa81fa","https://git.kernel.org/stable/c/8b3e4d26bc9cd0f6373d0095b9ffd99e7da8006b","https://git.kernel.org/stable/c/c7953cf03a26876d676145ce5d2ae6d8c9630b90","https://git.kernel.org/stable/c/df7e088d51cdf78b1a0bf1f3d405c2593295c7b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46759 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwmon: (adc128d818) Fix underflows seen when writing limit attributes DIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large negative number such as -9223372036854775808 is provided by the user. Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations. | ["https://git.kernel.org/stable/c/019ef2d396363ecddc46e826153a842f8603799b","https://git.kernel.org/stable/c/05419d0056dcf7088687e561bb583cc06deba777","https://git.kernel.org/stable/c/2a3add62f183459a057336381ef3a896da01ce38","https://git.kernel.org/stable/c/6891b11a0c6227ca7ed15786928a07b1c0e4d4af","https://git.kernel.org/stable/c/7645d783df23878342d5d8d22030c3861d2d5426","https://git.kernel.org/stable/c/8cad724c8537fe3e0da8004646abc00290adae40","https://git.kernel.org/stable/c/b0bdb43852bf7f55ba02f0cbf00b4ea7ca897bff","https://git.kernel.org/stable/c/f7f5101af5b47a331cdbfa42ba64c507b47dd1fe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44941 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to cover read extent cache access with lock syzbot reports a f2fs bug as below: BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097 CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 do_read_inode fs/f2fs/inode.c:509 [inline] f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560 f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237 generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413 exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444 exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584 do_handle_to_path fs/fhandle.c:155 [inline] handle_to_path fs/fhandle.c:210 [inline] do_handle_open+0x495/0x650 fs/fhandle.c:226 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f We missed to cover sanity_check_extent_cache() w/ extent cache lock, so, below race case may happen, result in use after free issue. - f2fs_iget - do_read_inode - f2fs_init_read_extent_tree : add largest extent entry in to cache - shrink - f2fs_shrink_read_extent_tree - __shrink_extent_tree - __detach_extent_node : drop largest extent entry - sanity_check_extent_cache : access et->largest w/o lock let's refactor sanity_check_extent_cache() to avoid extent cache access and call it before f2fs_init_read_extent_tree() to fix this issue. | ["https://git.kernel.org/stable/c/263df78166d3a9609b97d28c34029bd01874cbb8","https://git.kernel.org/stable/c/323ef20b5558b9d9fd10c1224327af6f11a8177d","https://git.kernel.org/stable/c/d7409b05a64f212735f0d33f5f1602051a886eab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48919 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: fix double free race when mount fails in cifs_get_root() When cifs_get_root() fails during cifs_smb3_do_mount() we call deactivate_locked_super() which eventually will call delayed_free() which will free the context. In this situation we should not proceed to enter the out: section in cifs_smb3_do_mount() and free the same resources a second time. [Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0 [Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.17.0-rc3+ #4 [Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 [Thu Feb 10 12:59:06 2022] Call Trace: [Thu Feb 10 12:59:06 2022] <IRQ> [Thu Feb 10 12:59:06 2022] dump_stack_lvl+0x5d/0x78 [Thu Feb 10 12:59:06 2022] print_address_description.constprop.0+0x24/0x150 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] kasan_report.cold+0x7d/0x117 [Thu Feb 10 12:59:06 2022] ? rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] __asan_load8+0x86/0xa0 [Thu Feb 10 12:59:06 2022] rcu_cblist_dequeue+0x32/0x60 [Thu Feb 10 12:59:06 2022] rcu_core+0x547/0xca0 [Thu Feb 10 12:59:06 2022] ? call_rcu+0x3c0/0x3c0 [Thu Feb 10 12:59:06 2022] ? __this_cpu_preempt_check+0x13/0x20 [Thu Feb 10 12:59:06 2022] ? lock_is_held_type+0xea/0x140 [Thu Feb 10 12:59:06 2022] rcu_core_si+0xe/0x10 [Thu Feb 10 12:59:06 2022] __do_softirq+0x1d4/0x67b [Thu Feb 10 12:59:06 2022] __irq_exit_rcu+0x100/0x150 [Thu Feb 10 12:59:06 2022] irq_exit_rcu+0xe/0x30 [Thu Feb 10 12:59:06 2022] sysvec_hyperv_stimer0+0x9d/0xc0 ... [Thu Feb 10 12:59:07 2022] Freed by task 58179: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] kasan_set_track+0x25/0x30 [Thu Feb 10 12:59:07 2022] kasan_set_free_info+0x24/0x40 [Thu Feb 10 12:59:07 2022] ____kasan_slab_free+0x137/0x170 [Thu Feb 10 12:59:07 2022] __kasan_slab_free+0x12/0x20 [Thu Feb 10 12:59:07 2022] slab_free_freelist_hook+0xb3/0x1d0 [Thu Feb 10 12:59:07 2022] kfree+0xcd/0x520 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0x149/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae [Thu Feb 10 12:59:07 2022] Last potentially related work creation: [Thu Feb 10 12:59:07 2022] kasan_save_stack+0x26/0x50 [Thu Feb 10 12:59:07 2022] __kasan_record_aux_stack+0xb6/0xc0 [Thu Feb 10 12:59:07 2022] kasan_record_aux_stack_noalloc+0xb/0x10 [Thu Feb 10 12:59:07 2022] call_rcu+0x76/0x3c0 [Thu Feb 10 12:59:07 2022] cifs_umount+0xce/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] cifs_kill_sb+0xc8/0xe0 [cifs] [Thu Feb 10 12:59:07 2022] deactivate_locked_super+0x5d/0xd0 [Thu Feb 10 12:59:07 2022] cifs_smb3_do_mount+0xab9/0xbe0 [cifs] [Thu Feb 10 12:59:07 2022] smb3_get_tree+0x1a0/0x2e0 [cifs] [Thu Feb 10 12:59:07 2022] vfs_get_tree+0x52/0x140 [Thu Feb 10 12:59:07 2022] path_mount+0x635/0x10c0 [Thu Feb 10 12:59:07 2022] __x64_sys_mount+0x1bf/0x210 [Thu Feb 10 12:59:07 2022] do_syscall_64+0x5c/0xc0 [Thu Feb 10 12:59:07 2022] entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/147a0e71ccf96df9fc8c2ac500829d8e423ef02c","https://git.kernel.org/stable/c/2fe0e281f7ad0a62259649764228227dd6b2561d","https://git.kernel.org/stable/c/3d6cc9898efdfb062efb74dc18cfc700e082f5d5","https://git.kernel.org/stable/c/546d60859ecf13380fcabcbeace53a5971493a2b","https://git.kernel.org/stable/c/563431c1f3c8f2230e4a9c445fa23758742bc4f0","https://git.kernel.org/stable/c/da834d6c1147c7519a9e55b510a03b7055104749","https://git.kernel.org/stable/c/df9db1a2af37f39ad1653c7b9b0d275d72d0bc67","https://git.kernel.org/stable/c/e208668ef7ba23efcbf76a8200cab8deee501c4d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-25258 | Medium | fixed |
|
An issue was discovered in drivers/usb/gadget/composite.c in the Linux kernel before 5.16.10. The USB Gadget subsystem lacks certain validation of interface OS descriptor requests (ones with a large array index and ones associated with NULL function pointer retrieval). Memory corruption might occur. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/d-os-descriptor","https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20221028-0007/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://github.com/szymonh/d-os-descriptor","https://github.com/torvalds/linux/commit/75e5b4849b81e19e9efe1654b30d7f3151c33c2c","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20221028-0007/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46679 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers. | ["https://git.kernel.org/stable/c/1d6d9b5b1b95bfeccb84386a51b7e6c510ec13b2","https://git.kernel.org/stable/c/7a8d98b6d6484d3ad358510366022da080c37cbc","https://git.kernel.org/stable/c/842a40c7273ba1c1cb30dda50405b328de1d860e","https://git.kernel.org/stable/c/94ab317024ba373d37340893d1c0358638935fbb","https://git.kernel.org/stable/c/9bba5955eed160102114d4cc00c3d399be9bdae4","https://git.kernel.org/stable/c/a699781c79ecf6cfe67fb00a0331b4088c7c8466","https://git.kernel.org/stable/c/ec7b4f7f644018ac293cb1b02528a40a32917e62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49599 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_l3mdev_accept. While reading sysctl_tcp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/08a75f10679470552a3a443f9aefd1399604d31d","https://git.kernel.org/stable/c/1d9c81833dec46ccb52a1d0db970fefb7c4fa071","https://git.kernel.org/stable/c/7d38d86b818104cf88961f3aebea34da89364a8e","https://git.kernel.org/stable/c/9ba9cd43b5776c27d25e5a32dde9e80bdeb1c6a1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42093 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/dpaa2: Avoid explicit cpumask var allocation on stack For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask variable on stack is not recommended since it can cause potential stack overflow. Instead, kernel code should always use *cpumask_var API(s) to allocate cpumask var in config-neutral way, leaving allocation strategy to CONFIG_CPUMASK_OFFSTACK. Use *cpumask_var API(s) to address it. | ["https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0","https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527","https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2","https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509","https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d","https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1","https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c","https://git.kernel.org/stable/c/48147337d7efdea6ad6e49f5b8eb894b95868ef0","https://git.kernel.org/stable/c/5e4f25091e6d06e99a23f724c839a58a8776a527","https://git.kernel.org/stable/c/69f49527aea12c23b78fb3d0a421950bf44fb4e2","https://git.kernel.org/stable/c/763896ab62a672d728f5eb10ac90d98c607a8509","https://git.kernel.org/stable/c/a55afc0f5f20ba30970aaf7271929dc00eee5e7d","https://git.kernel.org/stable/c/b2262b3be27cee334a2fa175ae3afb53f38fb0b1","https://git.kernel.org/stable/c/d33fe1714a44ff540629b149d8fab4ac6967585c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36910 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Don't free decrypted memory In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. The VMBus device UIO driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory. | ["https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7","https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9","https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54","https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23","https://git.kernel.org/stable/c/3d788b2fbe6a1a1a9e3db09742b90809d51638b7","https://git.kernel.org/stable/c/6466a0f6d235c8a18c602cb587160d7e49876db9","https://git.kernel.org/stable/c/dabf12bf994318d939f70d47cfda30e47abb2c54","https://git.kernel.org/stable/c/fe2c58602354fbd60680dc42ac3a0b772cda7d23"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52844 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: psi: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9","https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0","https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad","https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d","https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a","https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9","https://git.kernel.org/stable/c/3387490c89b10aeb4e71d78b65dbc9ba4b2385b9","https://git.kernel.org/stable/c/5c26aae3723965c291c65dd2ecad6a3240d422b0","https://git.kernel.org/stable/c/5cfcc8de7d733a1137b86954cc28ce99972311ad","https://git.kernel.org/stable/c/76a2c5df6ca8bd8ada45e953b8c72b746f42918d","https://git.kernel.org/stable/c/a51335704a3f90eaf23a6864faefca34b382490a","https://git.kernel.org/stable/c/d17269fb9161995303985ab2fe6f16cfb72152f9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52858 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0","https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa","https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee","https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d","https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0","https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e","https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94","https://git.kernel.org/stable/c/1d89430fc3158f872d492f1b88d07262f48290c0","https://git.kernel.org/stable/c/2befa515c1bb6cdd33c262b909d93d1973a219aa","https://git.kernel.org/stable/c/4f861b63945e076f9f003a5fad958174096df1ee","https://git.kernel.org/stable/c/5fbea47eebff5daeca7d918c99289bcd3ae4dc8d","https://git.kernel.org/stable/c/a836efc21ef04608333d6d05753e558ebd1f85d0","https://git.kernel.org/stable/c/e8ae4b49dd9cfde69d8de8c0c0cd7cf1b004482e","https://git.kernel.org/stable/c/e964d21dc034b650d719c4ea39564bec72b42f94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2016-3699 | High | N/A | The Linux kernel, as used in Red Hat Enterprise Linux 7.2 and Red Hat Enterprise MRG 2 and when booted with UEFI Secure Boot enabled, allows local users to bypass intended Secure Boot restrictions and execute untrusted code by appending ACPI tables to the initrd. | ["http://rhn.redhat.com/errata/RHSA-2016-2574.html","http://rhn.redhat.com/errata/RHSA-2016-2584.html","http://www.openwall.com/lists/oss-security/2016/09/22/4","http://www.securityfocus.com/bid/93114","https://bugzilla.redhat.com/show_bug.cgi?id=1329653","https://github.com/mjg59/linux/commit/a4a5ed2835e8ea042868b7401dced3f517cafa76","http://rhn.redhat.com/errata/RHSA-2016-2574.html","http://rhn.redhat.com/errata/RHSA-2016-2584.html","http://www.openwall.com/lists/oss-security/2016/09/22/4","http://www.securityfocus.com/bid/93114","https://bugzilla.redhat.com/show_bug.cgi?id=1329653","https://github.com/mjg59/linux/commit/a4a5ed2835e8ea042868b7401dced3f517cafa76"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46721 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: apparmor: fix possible NULL pointer dereference profile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is made from __create_missing_ancestors(..) and 'ent->old' is NULL in aa_replace_profiles(..). In that case, it must return an error code and the code, -ENOENT represents its state that the path of its parent is not existed yet. BUG: kernel NULL pointer dereference, address: 0000000000000030 PGD 0 P4D 0 PREEMPT SMP PTI CPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0 Call Trace: <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80 RIP: 0033:0x7be9f211c574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574 RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004 RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80 R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 </TASK> Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas CR2: 0000000000000030 ---[ end trace 0000000000000000 ]--- RIP: 0010:aafs_create.constprop.0+0x7f/0x130 Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae RSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000 ---truncated--- | ["https://git.kernel.org/stable/c/09b2d107fe63e55b6ae643f9f26bf8eb14a261d9","https://git.kernel.org/stable/c/3dd384108d53834002be5630132ad5c3f32166ad","https://git.kernel.org/stable/c/52338a3aa772762b8392ce7cac106c1099aeab85","https://git.kernel.org/stable/c/59f742e55a469ef36c5c1533b6095a103b61eda8","https://git.kernel.org/stable/c/730ee2686af0d55372e97a2695005ff142702363","https://git.kernel.org/stable/c/8d9da10a392a32368392f7a16775e1f36e2a5346","https://git.kernel.org/stable/c/c49bbe69ee152bd9c1c1f314c0f582e76c578f64","https://git.kernel.org/stable/c/e3c7d23f7a5c0b11ba0093cea32261ab8098b94e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46755 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id() mwifiex_get_priv_by_id() returns the priv pointer corresponding to the bss_num and bss_type, but without checking if the priv is actually currently in use. Unused priv pointers do not have a wiphy attached to them which can lead to NULL pointer dereferences further down the callstack. Fix this by returning only used priv pointers which have priv->bss_mode set to something else than NL80211_IFTYPE_UNSPECIFIED. Said NULL pointer dereference happened when an Accesspoint was started with wpa_supplicant -i mlan0 with this config: network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678" } When waiting for the AP to be established, interrupting wpa_supplicant with <ctrl-c> and starting it again this happens: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000 | [0000000000000140] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio +mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs +imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6 | CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18 | Hardware name: somemachine (DT) | Workqueue: events sdio_irq_work | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex] | lr : mwifiex_get_cfp+0x34/0x15c [mwifiex] | sp : ffff8000818b3a70 | x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004 | x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9 | x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000 | x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000 | x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517 | x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1 | x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157 | x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124 | x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000 | x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000 | Call trace: | mwifiex_get_cfp+0xd8/0x15c [mwifiex] | mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex] | mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex] | mwifiex_process_sta_event+0x298/0xf0c [mwifiex] | mwifiex_process_event+0x110/0x238 [mwifiex] | mwifiex_main_process+0x428/0xa44 [mwifiex] | mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio] | process_sdio_pending_irqs+0x64/0x1b8 | sdio_irq_work+0x4c/0x7c | process_one_work+0x148/0x2a0 | worker_thread+0x2fc/0x40c | kthread+0x110/0x114 | ret_from_fork+0x10/0x20 | Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000) | ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/1a05d8d02cfa3540ea5dbd6b39446bd3f515521f","https://git.kernel.org/stable/c/9813770f25855b866b8ead8155b8806b2db70f6d","https://git.kernel.org/stable/c/a12cf97cbefa139ef8d95081f2ea047cbbd74b7a","https://git.kernel.org/stable/c/c145eea2f75ff7949392aebecf7ef0a81c1f6c14","https://git.kernel.org/stable/c/c16916dd6c16fa7e13ca3923eb6b9f50d848ad03","https://git.kernel.org/stable/c/c2618dcb26c7211342b54520b5b148c0d3471c8a","https://git.kernel.org/stable/c/cb67b2e51b75f1a17bee7599c8161b96e1808a70","https://git.kernel.org/stable/c/d834433ff313838a259bb6607055ece87b895b66"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46761 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pci/hotplug/pnv_php: Fix hotplug driver crash on Powernv The hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel crash when we try to hot-unplug/disable the PCIe switch/bridge from the PHB. The crash occurs because although the MSI data structure has been released during disable/hot-unplug path and it has been assigned with NULL, still during unregistration the code was again trying to explicitly disable the MSI which causes the NULL pointer dereference and kernel crash. The patch fixes the check during unregistration path to prevent invoking pci_disable_msi/msix() since its data structure is already freed. | ["https://git.kernel.org/stable/c/335e35b748527f0c06ded9eebb65387f60647fda","https://git.kernel.org/stable/c/438d522227374042b5c8798f8ce83bbe479dca4d","https://git.kernel.org/stable/c/4eb4085c1346d19d4a05c55246eb93e74e671048","https://git.kernel.org/stable/c/b82d4d5c736f4fd2ed224c35f554f50d1953d21e","https://git.kernel.org/stable/c/bc1faed19db95abf0933b104910a3fb01b138f59","https://git.kernel.org/stable/c/bfc44075b19740d372f989f21dd03168bfda0689","https://git.kernel.org/stable/c/c0d8094dc740cfacf3775bbc6a1c4720459e8de4","https://git.kernel.org/stable/c/c4c681999d385e28f84808bbf3a85ea8e982da55"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50299 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 | ["https://git.kernel.org/stable/c/0ead60804b64f5bd6999eec88e503c6a1a242d41","https://git.kernel.org/stable/c/40b283ba76665437bc2ac72079c51b57b25bff9e","https://git.kernel.org/stable/c/67b9a278b80f71ec62091ded97c6bcbea33b5ec3","https://git.kernel.org/stable/c/8820d2d6589f62ee5514793fff9b50c9f8101182","https://git.kernel.org/stable/c/9b5d42aeaf1a52f73b003a33da6deef7df34685f","https://git.kernel.org/stable/c/a758aa6a773bb872196bcc3173171ef8996bddf0","https://git.kernel.org/stable/c/bf9bff13225baf5f658577f7d985fc4933d79527","https://git.kernel.org/stable/c/d3fb3cc83cf313e4f87063ce0f3fea76b071567b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53060 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported acpi_evaluate_object() may return AE_NOT_FOUND (failure), which would result in dereferencing buffer.pointer (obj) while being NULL. Although this case may be unrealistic for the current code, it is still better to protect against possible bugs. Bail out also when status is AE_NOT_FOUND. This fixes 1 FORWARD_NULL issue reported by Coverity Report: CID 1600951: Null pointer dereferences (FORWARD_NULL) (cherry picked from commit 91c9e221fe2553edf2db71627d8453f083de87a1) | ["https://git.kernel.org/stable/c/1a9f55ed5b512f510ccd21ad527d532e60550e80","https://git.kernel.org/stable/c/27fc29b5376998c126c85cf9b15d9dfc2afc9cbe","https://git.kernel.org/stable/c/2ac7f253deada4d449559b65a1c1cd0a6f6f19b7","https://git.kernel.org/stable/c/8d7a28eca7553d35d4ce192fa1f390f2357df41b","https://git.kernel.org/stable/c/a613a392417532ca5aaf3deac6e3277aa7aaef2b","https://git.kernel.org/stable/c/a6dd15981c03f2cdc9a351a278f09b5479d53d2e","https://git.kernel.org/stable/c/b9d9881237afeb52eddd70077b7174bf17e2fa30","https://git.kernel.org/stable/c/ce8a00a00e36f61f5a1e47734332420b68784c43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38553 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed. | ["https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f","https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243","https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5","https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e","https://git.kernel.org/stable/c/e2348d8c61d03feece1de4c05f72e6e99f74c650","https://git.kernel.org/stable/c/87bcbc9b7e0b43a69d44efa5f32f11e32d08fa6f","https://git.kernel.org/stable/c/accdd6b912c4219b8e056d1f1ad2e85bc66ee243","https://git.kernel.org/stable/c/c2e0c58b25a0a0c37ec643255558c5af4450c9f5","https://git.kernel.org/stable/c/d38625f71950e79e254515c5fc585552dad4b33e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42063 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf prog stack with kmsan_unposion_memory in interpreter mode syzbot reported uninit memory usages during map_{lookup,delete}_elem. ========== BUG: KMSAN: uninit-value in __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] BUG: KMSAN: uninit-value in dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 __dev_map_lookup_elem kernel/bpf/devmap.c:441 [inline] dev_map_lookup_elem+0xf3/0x170 kernel/bpf/devmap.c:796 ____bpf_map_lookup_elem kernel/bpf/helpers.c:42 [inline] bpf_map_lookup_elem+0x5c/0x80 kernel/bpf/helpers.c:38 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run256+0xb5/0xe0 kernel/bpf/core.c:2237 ========== The reproducer should be in the interpreter mode. The C reproducer is trying to run the following bpf prog: 0: (18) r0 = 0x0 2: (18) r1 = map[id:49] 4: (b7) r8 = 16777216 5: (7b) *(u64 *)(r10 -8) = r8 6: (bf) r2 = r10 7: (07) r2 += -229 ^^^^^^^^^^ 8: (b7) r3 = 8 9: (b7) r4 = 0 10: (85) call dev_map_lookup_elem#1543472 11: (95) exit It is due to the "void *key" (r2) passed to the helper. bpf allows uninit stack memory access for bpf prog with the right privileges. This patch uses kmsan_unpoison_memory() to mark the stack as initialized. This should address different syzbot reports on the uninit "void *key" argument during map_{lookup,delete}_elem. | ["https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12","https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5","https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf","https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979","https://git.kernel.org/stable/c/3189983c26108cf0990e5c46856dc9feb9470d12","https://git.kernel.org/stable/c/b30f3197a6cd080052d5d4973f9a6b479fd9fff5","https://git.kernel.org/stable/c/d812ae6e02bd6e6a9cd1fdb09519c2f33e875faf","https://git.kernel.org/stable/c/e8742081db7d01f980c6161ae1e8a1dbc1e30979"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45018 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: initialise extack before use Fix missing initialisation of extack in flow offload. | ["https://git.kernel.org/stable/c/119be227bc04f5035efa64cb823b8a5ca5e2d1c1","https://git.kernel.org/stable/c/356beb911b63a8cff34cb57f755c2a2d2ee9dec7","https://git.kernel.org/stable/c/7eafeec6be68ebd6140a830ce9ae68ad5b67ec78","https://git.kernel.org/stable/c/c7b760499f7791352b49b11667ed04b23d7f5b0f","https://git.kernel.org/stable/c/e5ceff2196dc633c995afb080f6f44a72cff6e1d","https://git.kernel.org/stable/c/e9767137308daf906496613fd879808a07f006a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26740 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: use the backlog for mirred ingress The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep. The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls. In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue. | ["https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17","https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be","https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4","https://git.kernel.org/stable/c/52f671db18823089a02f07efc04efdb2272ddc17","https://git.kernel.org/stable/c/60ddea1600bc476e0f5e02bce0e29a460ccbf0be","https://git.kernel.org/stable/c/7c787888d164689da8b1b115f3ef562c1e843af4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48648 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sfc: fix null pointer dereference in efx_hard_start_xmit Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it. I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] | ["https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3","https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998","https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7","https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03","https://git.kernel.org/stable/c/0a242eb2913a4aa3d6fbdb86559f27628e9466f3","https://git.kernel.org/stable/c/8547c7bfc0617e7184e4da65b9b96681fcfe9998","https://git.kernel.org/stable/c/b3b41d4d95d3822b2e459ecbc80d030ea6aec5e7","https://git.kernel.org/stable/c/b3b952168ee1f220ba729fa100fd9d5aa752eb03"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39471 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add error handle to avoid out-of-bounds if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should be stop to avoid out-of-bounds read, so directly return -EINVAL. | ["https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46","https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3","https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8","https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691","https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f","https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520","https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a","https://git.kernel.org/stable/c/011552f29f20842c9a7a21bffe1f6a2d6457ba46","https://git.kernel.org/stable/c/0964c84b93db7fbf74f357c1e20957850e092db3","https://git.kernel.org/stable/c/5594971e02764aa1c8210ffb838cb4e7897716e8","https://git.kernel.org/stable/c/5b0a3dc3e87821acb80e841b464d335aff242691","https://git.kernel.org/stable/c/8112fa72b7f139052843ff484130d6f97e9f052f","https://git.kernel.org/stable/c/8b2faf1a4f3b6c748c0da36cda865a226534d520","https://git.kernel.org/stable/c/ea906e9ac61e3152bef63597f2d9f4a812fc346a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41059 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hfsplus: fix uninit-value in copy_name [syzbot reported] BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160 sized_strscpy+0xc4/0x160 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3877 [inline] slab_alloc_node mm/slub.c:3918 [inline] kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065 kmalloc include/linux/slab.h:628 [inline] hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699 vfs_listxattr fs/xattr.c:493 [inline] listxattr+0x1f3/0x6b0 fs/xattr.c:840 path_listxattr fs/xattr.c:864 [inline] __do_sys_listxattr fs/xattr.c:876 [inline] __se_sys_listxattr fs/xattr.c:873 [inline] __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Fix] When allocating memory to strbuf, initialize memory to 0. | ["https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d","https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c","https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0","https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335","https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2","https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4","https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70","https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a","https://git.kernel.org/stable/c/0570730c16307a72f8241df12363f76600baf57d","https://git.kernel.org/stable/c/22999936b91ba545ce1fbbecae6895127945e91c","https://git.kernel.org/stable/c/34f8efd2743f2d961e92e8e994de4c7a2f9e74a0","https://git.kernel.org/stable/c/72805debec8f7aa342da194fe0ed7bc8febea335","https://git.kernel.org/stable/c/ad57dc2caf1e0a3c0a9904400fae7afbc9f74bb2","https://git.kernel.org/stable/c/c733e24a61cbcff10f660041d6d84d32bb7e4cb4","https://git.kernel.org/stable/c/d02d8c1dacafb28930c39e16d48e40bb6e4cbc70","https://git.kernel.org/stable/c/f08956d8e0f80fd0d4ad84ec917302bb2f3a9c6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50033 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 | ["https://git.kernel.org/stable/c/29e8d96d44f51cf89a62dd042be35d052833b95c","https://git.kernel.org/stable/c/36b054324d18e51cf466134e13b6fbe3c91f52af","https://git.kernel.org/stable/c/5e336384cc9b608e0551f99c3d87316ca3b0e51a","https://git.kernel.org/stable/c/7d3fce8cbe3a70a1c7c06c9b53696be5d5d8dd5c","https://git.kernel.org/stable/c/8bb79eb1db85a10865f0d4dd15b013def3f2d246","https://git.kernel.org/stable/c/ba6501ea06462d6404d57d5644cf2854db38e7d7","https://git.kernel.org/stable/c/ff5e0f895315706e4ca5a19df15be6866cee4f5d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27020 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get() nft_unregister_expr() can concurrent with __nft_expr_type_get(), and there is not any protection when iterate over nf_tables_expressions list in __nft_expr_type_get(). Therefore, there is potential data-race of nf_tables_expressions list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_expressions list in __nft_expr_type_get(), and use rcu_read_lock() in the caller nft_expr_type_get() to protect the entire type query process. | ["https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f","https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907","https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5","https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05","https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a","https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b","https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c","https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf","https://git.kernel.org/stable/c/01f1a678b05ade4b1248019c2dcca773aebbeb7f","https://git.kernel.org/stable/c/0b6de00206adbbfc6373b3ae38d2a6f197987907","https://git.kernel.org/stable/c/8d56bad42ac4c43c6c72ddd6a654a2628bf839c5","https://git.kernel.org/stable/c/934e66e231cff2b18faa2c8aad0b8cec13957e05","https://git.kernel.org/stable/c/939109c0a8e2a006a6cc8209e262d25065f4403a","https://git.kernel.org/stable/c/a9ebf340d123ae12582210407f879d6a5a1bc25b","https://git.kernel.org/stable/c/b38a133d37fa421c8447b383d788c9cc6f5cb34c","https://git.kernel.org/stable/c/f969eb84ce482331a991079ab7a5c4dc3b7f89bf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48873 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Don't remove map on creater_process and device_release Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead. The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0. | ["https://git.kernel.org/stable/c/193cd853145b63e670bd73740250983af1475330","https://git.kernel.org/stable/c/1b7b7bb400dd13dcb03fc6e591bb7ca4664bbec8","https://git.kernel.org/stable/c/35ddd482345c43d9eec1f3406c0f20a95ed4054b","https://git.kernel.org/stable/c/4b5c44e924a571d0ad07054de549624fbc04e4d7","https://git.kernel.org/stable/c/5bb96c8f9268e2fdb0e5321cbc358ee5941efc15"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27045 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10 | ["https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877","https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141","https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7","https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4","https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab","https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65","https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515","https://git.kernel.org/stable/c/440f059837418fac1695b65d3ebc6080d33be877","https://git.kernel.org/stable/c/4b09715f1504f1b6e8dff0e9643630610bc05141","https://git.kernel.org/stable/c/ad76fd30557d6a106c481e4606a981221ca525f7","https://git.kernel.org/stable/c/cf114d8d4a8d78df272116a745bb43b48cef65f4","https://git.kernel.org/stable/c/d346b3e5b25c95d504478507eb867cd3818775ab","https://git.kernel.org/stable/c/eb9327af3621d26b1d83f767c97a3fe8191a3a65","https://git.kernel.org/stable/c/ff28893c96c5e0927a4da10cd24a3522ca663515","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47697 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. | ["https://git.kernel.org/stable/c/042b101d7bf70616c4967c286ffa6fcca65babfb","https://git.kernel.org/stable/c/3dba83d3c81de1368d15a39f22df7b53e306052f","https://git.kernel.org/stable/c/46d7ebfe6a75a454a5fa28604f0ef1491f9d8d14","https://git.kernel.org/stable/c/58f31be7dfbc0c84a6497ad51924949cf64b86a2","https://git.kernel.org/stable/c/7fd6aae7e53b94f4035b1bfce28b8dfa0d0ae470","https://git.kernel.org/stable/c/86d920d2600c3a48efc2775c1666c1017eec6956","https://git.kernel.org/stable/c/883f794c6e498ae24680aead55c16f66b06cfc30","https://git.kernel.org/stable/c/8ffbe7d07b8e76193b151107878ddc1ccc94deb5","https://git.kernel.org/stable/c/badbd736e6649c4e6d7b4ff7e2b9857acfa9ea94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47698 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] | ["https://git.kernel.org/stable/c/15bea004e939d938a6771dfcf2a26cc899ffd20a","https://git.kernel.org/stable/c/49b33c38d202d3327dcfd058e27f541dcc308b92","https://git.kernel.org/stable/c/527ab3eb3b0b4a6ee00e183c1de6a730239e2835","https://git.kernel.org/stable/c/66dbe0df6eccc7ee53a2c35016ce81e13b3ff447","https://git.kernel.org/stable/c/6ae3b9aee42616ee93c4585174f40c767828006d","https://git.kernel.org/stable/c/7065c05c6d58b9b9a98127aa14e9a5ec68173918","https://git.kernel.org/stable/c/8ae06f360cfaca2b88b98ca89144548b3186aab1","https://git.kernel.org/stable/c/a879b6cdd48134a3d58949ea4f075c75fa2d7d71","https://git.kernel.org/stable/c/bedd42e07988dbdd124b23e758ffef7a681b9c60"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47701 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 </TASK> Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem. | ["https://git.kernel.org/stable/c/2a6579ef5f2576a940125729f7409cc182f1c8df","https://git.kernel.org/stable/c/371d0bacecd529f887ea2547333d9173e7bcdc0a","https://git.kernel.org/stable/c/5b076d37e8d99918e9294bd6b35a8bbb436819b0","https://git.kernel.org/stable/c/7fc22c3b3ffc0e952f5e0062dd11aa6ae76affba","https://git.kernel.org/stable/c/8adf0eb4e361a9e060d54f4bd0ac9c5d85277d20","https://git.kernel.org/stable/c/be2e9b111e2790962cc66a177869b4e9717b4e29","https://git.kernel.org/stable/c/c6b72f5d82b1017bad80f9ebf502832fc321d796","https://git.kernel.org/stable/c/ccb8c18076e2e630fea23fbec583cdad61787fc5","https://git.kernel.org/stable/c/ea32883e4a03ed575a2eb7a66542022312bde477"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49882 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: <TASK> __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================ | ["https://git.kernel.org/stable/c/230ee0535d01478bad9a3037292043f39b9be10b","https://git.kernel.org/stable/c/32bbb59e3f18facd7201bef110010bf35819b8c3","https://git.kernel.org/stable/c/68a69cf60660c73990c1875f94a5551600b04775","https://git.kernel.org/stable/c/7633407ca4ab8be2916ab214eb44ccebc6a50e1a","https://git.kernel.org/stable/c/78bbc3d15b6f443acb26e94418c445bac940d414","https://git.kernel.org/stable/c/b6c29c8f3d7cb67b505f3b2f6c242d52298d1f2e","https://git.kernel.org/stable/c/d4574bda63906bf69660e001470bfe1a0ac524ae","https://git.kernel.org/stable/c/dcaa6c31134c0f515600111c38ed7750003e1b9c","https://git.kernel.org/stable/c/f9fd47c9d9548f9e47fa60098eab99dde175401d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49883 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: <TASK> ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem. | ["https://git.kernel.org/stable/c/51db04892a993cace63415be99848970a0f15ef2","https://git.kernel.org/stable/c/5e811066c5ab709b070659197dccfb80ab650ddd","https://git.kernel.org/stable/c/8162ee5d94b8c0351be0a9321be134872a7654a1","https://git.kernel.org/stable/c/975ca06f3fd154c5f7742083e7b2574c57d1c0c3","https://git.kernel.org/stable/c/9df59009dfc6d9fc1bd9ddf6c5ab6e56d6ed887a","https://git.kernel.org/stable/c/a164f3a432aae62ca23d03e6d926b122ee5b860d","https://git.kernel.org/stable/c/beb7b66fb489041c50c6473100b383f7a51648fc","https://git.kernel.org/stable/c/bfed082ce4b1ce6349b05c09a0fa4f3da35ecb1b","https://git.kernel.org/stable/c/e17ebe4fdd7665c93ae9459ba40fcdfb76769ac1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49884 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: <TASK> kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates. | ["https://git.kernel.org/stable/c/393a46f60ea4f249dc9d496d4eb2d542f5e11ade","https://git.kernel.org/stable/c/448100a29395b0c8b4c42967155849fe0fbe808f","https://git.kernel.org/stable/c/5d949ea75bb529ea6342e83465938a3b0ac51238","https://git.kernel.org/stable/c/8fe117790b37c84c651e2bad9efc0e7fda73c0e3","https://git.kernel.org/stable/c/915ac3630488af0ca194dc63b86d99802b4f6e18","https://git.kernel.org/stable/c/a5401d4c3e2a3d25643c567d26e6de327774a2c9","https://git.kernel.org/stable/c/c26ab35702f8cd0cdc78f96aa5856bfb77be798f","https://git.kernel.org/stable/c/cafcc1bd62934547c76abf46c6d0d54f135006fe","https://git.kernel.org/stable/c/e52f933598b781d291b9297e39c463536da0e185"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49966 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails. | ["https://git.kernel.org/stable/c/0d707a33c84b371cb66120e198eed3374726ddd8","https://git.kernel.org/stable/c/14114d8148db07e7946fb06b56a50cfa425e26c7","https://git.kernel.org/stable/c/35fccce29feb3706f649726d410122dd81b92c18","https://git.kernel.org/stable/c/4173d1277c00baeedaaca76783e98b8fd0e3c08d","https://git.kernel.org/stable/c/89043e7ed63c7fc141e68ea5a79758ed24b6c699","https://git.kernel.org/stable/c/a4346c04d055bf7e184c18a73dbd23b6a9811118","https://git.kernel.org/stable/c/bbf41277df8b33fbedf4750a9300c147e8f104eb","https://git.kernel.org/stable/c/ef768020366f47d23f39c4f57bcb03af6d1e24b3","https://git.kernel.org/stable/c/fc5cc716dfbdc5fd5f373ff3b51358174cf88bfc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38577 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow There is a possibility of buffer overflow in show_rcu_tasks_trace_gp_kthread() if counters, passed to sprintf() are huge. Counter numbers, needed for this are unrealistically high, but buffer overflow is still possible. Use snprintf() with buffer size instead of sprintf(). Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222","https://git.kernel.org/stable/c/17c43211d45f13d1badea3942b76bf16bcc49281","https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7","https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec","https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697","https://git.kernel.org/stable/c/af7b560c88fb420099e29890aa682b8a3efc8784","https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48","https://git.kernel.org/stable/c/08186d0c5fb64a1cc4b43e009314ee6b173ed222","https://git.kernel.org/stable/c/1a240e138071b25944ded0f5b3e357aa99fabcb7","https://git.kernel.org/stable/c/32d988f48ed287e676a29a15ac30701c35849aec","https://git.kernel.org/stable/c/6593d857ce5b5b802fb73d8091ac9c84b92c1697","https://git.kernel.org/stable/c/cc5645fddb0ce28492b15520306d092730dffa48"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39480 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kdb: Fix buffer overflow during tab-complete Currently, when the user attempts symbol completion with the Tab key, kdb will use strncpy() to insert the completed symbol into the command buffer. Unfortunately it passes the size of the source buffer rather than the destination to strncpy() with predictably horrible results. Most obviously if the command buffer is already full but cp, the cursor position, is in the middle of the buffer, then we will write past the end of the supplied buffer. Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() calls plus explicit boundary checks to make sure we have enough space before we start moving characters around. | ["https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5","https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7","https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96","https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a","https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454","https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33","https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7","https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992","https://git.kernel.org/stable/c/107e825cc448b7834b31e8b1b3cf0f57426d46d5","https://git.kernel.org/stable/c/33d9c814652b971461d1e30bead6792851c209e7","https://git.kernel.org/stable/c/cfdc2fa4db57503bc6d3817240547c8ddc55fa96","https://git.kernel.org/stable/c/ddd2972d8e2dee3b33e8121669d55def59f0be8a","https://git.kernel.org/stable/c/e9730744bf3af04cda23799029342aa3cddbc454","https://git.kernel.org/stable/c/f636a40834d22e5e3fc748f060211879c056cd33","https://git.kernel.org/stable/c/f694da720dcf795dc3eb97bf76d220213f76aaa7","https://git.kernel.org/stable/c/fb824a99e148ff272a53d71d84122728b5f00992"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44942 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace: f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline] f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315 do_writepages+0x35b/0x870 mm/page-writeback.c:2612 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117 wb_do_writeback fs/fs-writeback.c:2264 [inline] wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416 kthread+0x2f2/0x390 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback. Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing. | ["https://git.kernel.org/stable/c/26c07775fb5dc74351d1c3a2bc3cdf609b03e49f","https://git.kernel.org/stable/c/ae00e6536a2dd54b64b39e9a39548870cf835745","https://git.kernel.org/stable/c/fc01008c92f40015aeeced94750855a7111b6929"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42076 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: can: j1939: Initialize unused data in j1939_send_one() syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one() creates full frame including unused data, but it doesn't initialize it. This causes the kernel-infoleak issue. Fix this by initializing unused data. [1] BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 12-15 of 16 are uninitialized Memory access of size 16 starts at ffff888120969690 Data copied to user address 00000000200017c0 CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 | ["https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f","https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf","https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4","https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f","https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134","https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298","https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b","https://git.kernel.org/stable/c/4c5dc3927e17489c1cae6f48c0d5e4acb4cae01f","https://git.kernel.org/stable/c/5e4ed38eb17eaca42de57d500cc0f9668d2b6abf","https://git.kernel.org/stable/c/a2a0ebff7fdeb2f66e29335adf64b9e457300dd4","https://git.kernel.org/stable/c/ab2a683938ba4416d389c2f5651cbbb2c41b779f","https://git.kernel.org/stable/c/b7cdf1dd5d2a2d8200efd98d1893684db48fe134","https://git.kernel.org/stable/c/ba7e5ae8208ac07d8e1eace0951a34c169a2d298","https://git.kernel.org/stable/c/f97cbce633923588307049c4aef9feb2987e371b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48856 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gianfar: ethtool: Fix refcount leak in gfar_get_ts_info The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. | ["https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848","https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a","https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0","https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6","https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c","https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9","https://git.kernel.org/stable/c/0e1b9a2078e07fb1e6e91bf8badfd89ecab1e848","https://git.kernel.org/stable/c/21044e679ed535345042d2023f7df0ca8e897e2a","https://git.kernel.org/stable/c/2ac5b58e645c66932438bb021cb5b52097ce70b0","https://git.kernel.org/stable/c/6263f2eb93a85ad7df504daf0c341a7fb6bbe8a6","https://git.kernel.org/stable/c/f49f646f9ec296fc0afe7ae92c2bb47f23e3846c","https://git.kernel.org/stable/c/f7b3b520349193f8a82cca74daf366199e06add9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFC: port100: fix use-after-free in port100_send_complete Syzbot reported UAF in port100_send_complete(). The root case is in missing usb_kill_urb() calls on error handling path of ->probe function. port100_send_complete() accesses devm allocated memory which will be freed on probe failure. We should kill this urbs before returning an error from probe function to prevent reported use-after-free Fail log: BUG: KASAN: use-after-free in port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 Read of size 1 at addr ffff88801bb59540 by task ksoftirqd/2/26 ... Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 port100_send_complete+0x16e/0x1a0 drivers/nfc/port100.c:935 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1670 ... Allocated by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:436 [inline] ____kasan_kmalloc mm/kasan/common.c:515 [inline] ____kasan_kmalloc mm/kasan/common.c:474 [inline] __kasan_kmalloc+0xa6/0xd0 mm/kasan/common.c:524 alloc_dr drivers/base/devres.c:116 [inline] devm_kmalloc+0x96/0x1d0 drivers/base/devres.c:823 devm_kzalloc include/linux/device.h:209 [inline] port100_probe+0x8a/0x1320 drivers/nfc/port100.c:1502 Freed by task 1255: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:366 [inline] ____kasan_slab_free+0xff/0x140 mm/kasan/common.c:328 kasan_slab_free include/linux/kasan.h:236 [inline] __cache_free mm/slab.c:3437 [inline] kfree+0xf8/0x2b0 mm/slab.c:3794 release_nodes+0x112/0x1a0 drivers/base/devres.c:501 devres_release_all+0x114/0x190 drivers/base/devres.c:530 really_probe+0x626/0xcc0 drivers/base/dd.c:670 | ["https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a","https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f","https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029","https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980","https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8","https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e","https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161","https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b","https://git.kernel.org/stable/c/0e721b8f2ee5e11376dd55363f9ccb539d754b8a","https://git.kernel.org/stable/c/205c4ec78e71cbf561794e6043da80e7bae6790f","https://git.kernel.org/stable/c/2b1c85f56512d49e43bc53741fce2f508cd90029","https://git.kernel.org/stable/c/32e866ae5a7af590597ef4bcff8451bf96d5f980","https://git.kernel.org/stable/c/7194737e1be8fdc89d2a9382bd2f371f7ee2eda8","https://git.kernel.org/stable/c/b1db33d4e54bc35d8db96ce143ea0ef92e23d58e","https://git.kernel.org/stable/c/cd2a5c0da0d1ddf11d1f84e9c9b1949f50f6e161","https://git.kernel.org/stable/c/f80cfe2f26581f188429c12bd937eb905ad3ac7b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48860 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ethernet: Fix error handling in xemaclite_of_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. As the remove function do. | ["https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4","https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d","https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9","https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549","https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6","https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1","https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584","https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f","https://git.kernel.org/stable/c/1852854ee349881efb78ccdbbb237838975902e4","https://git.kernel.org/stable/c/5e7c402892e189a7bc152b125e72261154aa585d","https://git.kernel.org/stable/c/669172ce976608b25a2f76f3c65d47f042d125c9","https://git.kernel.org/stable/c/8609e29611befc4bfbe7a91bb50fc65ae72ff549","https://git.kernel.org/stable/c/8ee065a7a9b6a3976c16340503677efc4d8351f6","https://git.kernel.org/stable/c/979b418b96e35f07136f77962ccfaa54cf3e30e1","https://git.kernel.org/stable/c/b19ab4b38b06aae12442b2de95ccf58b5dc53584","https://git.kernel.org/stable/c/b7220f8e9d6c6b9594ddfb3125dad938cd478b1f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42236 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: configfs: Prevent OOB read/write in usb_string_copy() Userspace provided string 's' could trivially have the length zero. Left unchecked this will firstly result in an OOB read in the form `if (str[0 - 1] == '\n') followed closely by an OOB write in the form `str[0 - 1] = '\0'`. There is already a validating check to catch strings that are too long. Let's supply an additional check for invalid strings that are too short. | ["https://git.kernel.org/stable/c/2d16f63d8030903e5031853e79d731ee5d474e70","https://git.kernel.org/stable/c/6d3c721e686ea6c59e18289b400cc95c76e927e0","https://git.kernel.org/stable/c/72b8ee0d9826e8ed00e0bdfce3e46b98419b37ce","https://git.kernel.org/stable/c/a444c3fc264119801575ab086e03fb4952f23fd0","https://git.kernel.org/stable/c/c95fbdde87e39e5e0ae27f28bf6711edfb985caa","https://git.kernel.org/stable/c/d1205033e912f9332c1dbefa812e6ceb0575ce0a","https://git.kernel.org/stable/c/e8474a10c535e6a2024c3b06e37e4a3a23beb490","https://git.kernel.org/stable/c/eecfefad0953b2f31aaefa058f7f348ff39c4bba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42286 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: validate nvme_local_port correctly The driver load failed with error message, qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef and with a kernel crash, BUG: unable to handle kernel NULL pointer dereference at 0000000000000070 Workqueue: events_unbound qla_register_fcport_fn [qla2xxx] RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc] RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000 RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000 RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030 R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4 R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8 FS: 0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0 Call Trace: qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx] ? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx] qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx] qla_register_fcport_fn+0x54/0xc0 [qla2xxx] Exit the qla_nvme_register_remote() function when qla_nvme_register_hba() fails and correctly validate nvme_local_port. | ["https://git.kernel.org/stable/c/3eac973eb5cb2b874b3918f924798afc5affd46b","https://git.kernel.org/stable/c/549aac9655320c9b245a24271b204668c5d40430","https://git.kernel.org/stable/c/7cec2c3bfe84539c415f5e16f989228eba1d2f1e","https://git.kernel.org/stable/c/a3ab508a4853a9f5ae25a7816a4889f09938f63c","https://git.kernel.org/stable/c/cde43031df533751b4ead37d173922feee2f550f","https://git.kernel.org/stable/c/e1f010844443c389bc552884ac5cfa47de34d54c","https://git.kernel.org/stable/c/eb1d4ce2609584eeb7694866f34d4b213caa3af9","https://git.kernel.org/stable/c/f6be298cc1042f24d521197af29c7c4eb95af4d5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42289 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: During vport delete send async logout explicitly During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting. BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 </TASK> Send out async logout explicitly for all the ports during vport delete. | ["https://git.kernel.org/stable/c/086489256696eb774654a5410e86381c346356fe","https://git.kernel.org/stable/c/171ac4b495f9473bc134356a00095b47e6409e52","https://git.kernel.org/stable/c/76f480d7c717368f29a3870f7d64471ce0ff8fb2","https://git.kernel.org/stable/c/87c25fcb95aafabb6a4914239f4ab41b07a4f9b7","https://git.kernel.org/stable/c/b12c54e51ba83c1fbc619d35083d7872e42ecdef","https://git.kernel.org/stable/c/b35d6d5a2f38605cddea7d5c64cded894fbe8ede","https://git.kernel.org/stable/c/d28a2075bb530489715a3b011e1dd8765ba20313","https://git.kernel.org/stable/c/e5ed6a26ffdec0c91cf0b6138afbd675c00ad5fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: core: check uartclk for zero to avoid divide by zero Calling ioctl TIOCSSERIAL with an invalid baud_base can result in uartclk being zero, which will result in a divide by zero error in uart_get_divisor(). The check for uartclk being zero in uart_set_info() needs to be done before other settings are made as subsequent calls to ioctl TIOCSSERIAL for the same port would be impacted if the uartclk check was done where uartclk gets set. Oops: divide error: 0000 PREEMPT SMP KASAN PTI RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580) Call Trace: <TASK> serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576 drivers/tty/serial/8250/8250_port.c:2589) serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502 drivers/tty/serial/8250/8250_port.c:2741) serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862) uart_change_line_settings (./include/linux/spinlock.h:376 ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222) uart_port_startup (drivers/tty/serial/serial_core.c:342) uart_startup (drivers/tty/serial/serial_core.c:368) uart_set_info (drivers/tty/serial/serial_core.c:1034) uart_set_info_user (drivers/tty/serial/serial_core.c:1059) tty_set_serial (drivers/tty/tty_io.c:2637) tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791) __x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907 fs/ioctl.c:893 fs/ioctl.c:893) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Rule: add | ["https://git.kernel.org/stable/c/3bbd90fca824e6fd61fb20f6dd2b0fa5f8b14bba","https://git.kernel.org/stable/c/52b138f1021113e593ee6ad258ce08fe90693a9e","https://git.kernel.org/stable/c/55b2a5d331a6ceb1c4372945fdb77181265ba24f","https://git.kernel.org/stable/c/68dc02f319b9ee54dc23caba742a5c754d1cccc8","https://git.kernel.org/stable/c/6eabce6608d6f3440f4c03aa3d3ef50a47a3d193","https://git.kernel.org/stable/c/9196e42a3b8eeff1707e6ef769112b4b6096be49","https://git.kernel.org/stable/c/e13ba3fe5ee070f8a9dab60029d52b1f61da5051","https://git.kernel.org/stable/c/e3ad503876283ac3fcca922a1bf243ef9eb0b0e2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43907 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules Check the pointer value to fix potential null pointer dereference | ["https://git.kernel.org/stable/c/0c065e50445aea2e0a1815f12e97ee49e02cbaac","https://git.kernel.org/stable/c/13937a40aae4efe64592ba48c057ac3c72f7fe82","https://git.kernel.org/stable/c/3a01bf2ca9f860fdc88c358567b8fa3033efcf30","https://git.kernel.org/stable/c/c1749313f35b98e2e655479f037db37f19756622","https://git.kernel.org/stable/c/d19fb10085a49b77578314f69fff21562f7cd054","https://git.kernel.org/stable/c/e04d18c29954441aa1054af649f957ffad90a201"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43914 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md/raid5: avoid BUG_ON() while continue reshape after reassembling Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test: kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace: <TASK> raid5_sync_request+0x43d/0x550 md_do_sync+0xb7a/0x2110 md_thread+0x294/0x2b0 kthread+0x147/0x1c0 ret_from_fork+0x59/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail. Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail. Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata. | ["https://git.kernel.org/stable/c/2c92f8c1c456d556f15cbf51667b385026b2e6a0","https://git.kernel.org/stable/c/305a5170dc5cf3d395bb4c4e9239bca6d0b54b49","https://git.kernel.org/stable/c/3b33740c1750a39e046339ff9240e954f0156707","https://git.kernel.org/stable/c/4811d6e5d9f4090c3e0ff9890eb24077108046ab","https://git.kernel.org/stable/c/6b33c468d543f6a83de2d61f09fec74b27e19fd2","https://git.kernel.org/stable/c/775a9ba16c9ffe98fe54ebf14e55d5660f2bf600","https://git.kernel.org/stable/c/bf0ff69a42a3d2d46876d0514ecf13dffc516666","https://git.kernel.org/stable/c/c384dd4f1fb3b14a2fd199360701cc163ea88705"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44960 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: Check for unset descriptor Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case. This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found. No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets. | ["https://git.kernel.org/stable/c/1a9df57d57452b104c46c918569143cf21d7ebf1","https://git.kernel.org/stable/c/50c5248b0ea8aae0529fdf28dac42a41312d3b62","https://git.kernel.org/stable/c/716cba46f73a92645cf13eded8d257ed48afc2a4","https://git.kernel.org/stable/c/7cc9ebcfe58be22f18056ad8bc6272d120bdcb3e","https://git.kernel.org/stable/c/973a57891608a98e894db2887f278777f564de18","https://git.kernel.org/stable/c/a0362cd6e503278add954123957fd47990e8d9bf","https://git.kernel.org/stable/c/ba15815dd24cc5ec0d23e2170dc58c7db1e03b4a","https://git.kernel.org/stable/c/df8e734ae5e605348aa0ca2498aedb73e815f244"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39472 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: xfs: fix log recovery buffer allocation for the legacy h_size fixup Commit a70f9fe52daa ("xfs: detect and handle invalid iclog size set by mkfs") added a fixup for incorrect h_size values used for the initial umount record in old xfsprogs versions. Later commit 0c771b99d6c9 ("xfs: clean up calculation of LR header blocks") cleaned up the log reover buffer calculation, but stoped using the fixed up h_size value to size the log recovery buffer, which can lead to an out of bounds access when the incorrect h_size does not come from the old mkfs tool, but a fuzzer. Fix this by open coding xlog_logrec_hblks and taking the fixed h_size into account for this calculation. | ["https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a","https://git.kernel.org/stable/c/57835c0e7152e36b03875dd6c56dfeed685c1b1f","https://git.kernel.org/stable/c/c2389c074973aa94e34992e7f66dac0de37595b5","https://git.kernel.org/stable/c/f754591b17d0ee91c2b45fe9509d0cdc420527cb","https://git.kernel.org/stable/c/45cf976008ddef4a9c9a30310c9b4fb2a9a6602a"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46772 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator crb_pipes before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 2 DIVIDE_BY_ZERO issues reported by Coverity. | ["https://git.kernel.org/stable/c/04805efe8623f8721f3c01182ea73d68e88c62d8","https://git.kernel.org/stable/c/b9264aa24f628eba5779d1c916441e0cedde9b3d","https://git.kernel.org/stable/c/ea79068d4073bf303f8203f2625af7d9185a1bc6","https://git.kernel.org/stable/c/ede06d23392529b039cf7ac11b5875b047900f1c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46823 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kunit/overflow: Fix UB in overflow_allocation_test The 'device_name' array doesn't exist out of the 'overflow_allocation_test' function scope. However, it is being used as a driver name when calling 'kunit_driver_create' from 'kunit_device_register'. It produces the kernel panic with KASAN enabled. Since this variable is used in one place only, remove it and pass the device name into kunit_device_register directly as an ascii string. | ["https://git.kernel.org/stable/c/92e9bac18124682c4b99ede9ee3bcdd68f121e92","https://git.kernel.org/stable/c/99ddb9c58511f1b71e23d02a06082bf6d2dd2133","https://git.kernel.org/stable/c/cacce7faa7c475cea55e82cc3a27794561fac157","https://git.kernel.org/stable/c/d1207f07decc66546a7fa463d2f335a856c986ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38559 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Ensure the copied buf is NUL terminated Currently, we allocate a count-sized kernel buffer and copy count from userspace to that buffer. Later, we use kstrtouint on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using kstrtouint. Fix this issue by using memdup_user_nul instead of memdup_user. | ["https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9","https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95","https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8","https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d","https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c","https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59","https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62","https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613","https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255","https://git.kernel.org/stable/c/177f43c6892e6055de6541fe9391a8a3d1f95fc9","https://git.kernel.org/stable/c/1f84a2744ad813be23fc4be99fb74bfb24aadb95","https://git.kernel.org/stable/c/4907f5ad246fa9b51093ed7dfc7da9ebbd3f20b8","https://git.kernel.org/stable/c/563e609275927c0b75fbfd0d90441543aa7b5e0d","https://git.kernel.org/stable/c/769b9fd2af02c069451fe9108dba73355d9a021c","https://git.kernel.org/stable/c/a75001678e1d38aa607d5b898ec7ff8ed0700d59","https://git.kernel.org/stable/c/d0184a375ee797eb657d74861ba0935b6e405c62","https://git.kernel.org/stable/c/d93318f19d1e1a6d5f04f5d965eaa9055bb7c613","https://git.kernel.org/stable/c/dccd97b39ab2f2b1b9a47a1394647a4d65815255"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46722 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix mc_data out-of-bounds read warning Clear warning that read mc_data[i-1] may out-of-bounds. | ["https://git.kernel.org/stable/c/2097edede72ec5bb3869cf0205337d392fb2a553","https://git.kernel.org/stable/c/310b9d8363b88e818afec97ca7652bd7fe3d0650","https://git.kernel.org/stable/c/345bd3ad387f9e121aaad9c95957b80895e2f2ec","https://git.kernel.org/stable/c/51dfc0a4d609fe700750a62f41447f01b8c9ea50","https://git.kernel.org/stable/c/578ae965e8b90cd09edeb0252b50fa0503ea35c5","https://git.kernel.org/stable/c/5fa4df25ecfc7b6c9006f5b871c46cfe25ea8826","https://git.kernel.org/stable/c/b862a0bc5356197ed159fed7b1c647e77bc9f653","https://git.kernel.org/stable/c/d0a43bf367ed640e527e8ef3d53aac1e71f80114"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46723 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix ucode out-of-bounds read warning Clear warning that read ucode[] may out-of-bounds. | ["https://git.kernel.org/stable/c/0bef65e069d84d1cd77ce757aea0e437b8e2bd33","https://git.kernel.org/stable/c/23fefef859c6057e6770584242bdd938254f8ddd","https://git.kernel.org/stable/c/5f09fa5e0ad45fbca71933a0e024ca52da47d59b","https://git.kernel.org/stable/c/82ac8f1d02886b5d8aeb9e058989d3bd6fc581e2","https://git.kernel.org/stable/c/8944acd0f9db33e17f387fdc75d33bb473d7936f","https://git.kernel.org/stable/c/8981927ebc6c12fa76b30c4178acb462bab15f54","https://git.kernel.org/stable/c/e789e05388854a5436b2b5d8695fdb864c9bcc27","https://git.kernel.org/stable/c/f2b7a9f3839e92f43559b2795b34640ca8cf839f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46743 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: of/irq: Prevent device address out-of-bounds read in interrupt map walk When of_irq_parse_raw() is invoked with a device address smaller than the interrupt parent node (from #address-cells property), KASAN detects the following out-of-bounds read when populating the initial match table (dyndbg="func of_irq_parse_* +p"): OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0 OF: parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2 OF: intspec=4 OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2 OF: -> addrsize=3 ================================================================== BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0 Read of size 4 at addr ffffff81beca5608 by task bash/764 CPU: 1 PID: 764 Comm: bash Tainted: G O 6.1.67-484c613561-nokia_sm_arm64 #1 Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023 Call trace: dump_backtrace+0xdc/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0x6c/0x84 print_report+0x150/0x448 kasan_report+0x98/0x140 __asan_load4+0x78/0xa0 of_irq_parse_raw+0x2b8/0x8d0 of_irq_parse_one+0x24c/0x270 parse_interrupts+0xc0/0x120 of_fwnode_add_links+0x100/0x2d0 fw_devlink_parse_fwtree+0x64/0xc0 device_add+0xb38/0xc30 of_device_add+0x64/0x90 of_platform_device_create_pdata+0xd0/0x170 of_platform_bus_create+0x244/0x600 of_platform_notify+0x1b0/0x254 blocking_notifier_call_chain+0x9c/0xd0 __of_changeset_entry_notify+0x1b8/0x230 __of_changeset_apply_notify+0x54/0xe4 of_overlay_fdt_apply+0xc04/0xd94 ... The buggy address belongs to the object at ffffff81beca5600 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 8 bytes inside of 128-byte region [ffffff81beca5600, ffffff81beca5680) The buggy address belongs to the physical page: page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4 head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0 flags: 0x8000000000010200(slab|head|zone=2) raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc ================================================================== OF: -> got it ! Prevent the out-of-bounds read by copying the device address into a buffer of sufficient size. | ["https://git.kernel.org/stable/c/7ead730af11ee7da107f16fc77995613c58d292d","https://git.kernel.org/stable/c/8ff351ea12e918db1373b915c4c268815929cbe5","https://git.kernel.org/stable/c/9d1e9f0876b03d74d44513a0ed3ed15ef8f2fed5","https://git.kernel.org/stable/c/b739dffa5d570b411d4bdf4bb9b8dfd6b7d72305","https://git.kernel.org/stable/c/baaf26723beab3a04da578d3008be3544f83758f","https://git.kernel.org/stable/c/bf68acd840b6a5bfd3777e0d5aaa204db6b461a9","https://git.kernel.org/stable/c/d2a79494d8a5262949736fb2c3ac44d20a51b0d8","https://git.kernel.org/stable/c/defcaa426ba0bc89ffdafb799d2e50b52f74ffc4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46747 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup report_fixup for the Cougar 500k Gaming Keyboard was not verifying that the report descriptor size was correct before accessing it | ["https://git.kernel.org/stable/c/30e9ce7cd5591be639b53595c95812f1a2afdfdc","https://git.kernel.org/stable/c/34185de73d74fdc90e8651cfc472bfea6073a13f","https://git.kernel.org/stable/c/48b2108efa205f4579052c27fba2b22cc6ad8aa0","https://git.kernel.org/stable/c/890dde6001b651be79819ef7a3f8c71fc8f9cabf","https://git.kernel.org/stable/c/a6e9c391d45b5865b61e569146304cff72821a5d","https://git.kernel.org/stable/c/e239e44dcd419b13cf840e2a3a833204e4329714","https://git.kernel.org/stable/c/e4a602a45aecd6a98b4b37482f5c9f8f67a32ddd","https://git.kernel.org/stable/c/fac3cb3c6428afe2207593a183b5bc4742529dfd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38538 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5","https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2","https://git.kernel.org/stable/c/3e01fc3c66e65d9afe98f1489047a1b2dd8741ca","https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a","https://git.kernel.org/stable/c/82090f94c723dab724b1c32db406091d40448a17","https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc","https://git.kernel.org/stable/c/b2b7c43cd32080221bb233741bd6011983fe7c11","https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d","https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2","https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5","https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2","https://git.kernel.org/stable/c/5b5d669f569807c7ab07546e73c0741845a2547a","https://git.kernel.org/stable/c/8bd67ebb50c0145fd2ca8681ab65eb7e8cde1afc","https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36e2488f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50036 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels. | ["https://git.kernel.org/stable/c/3c7c918ec0aa3555372c5a57f18780b7a96c5cfc","https://git.kernel.org/stable/c/547087307bc19417b4f2bc85ba9664a3e8db5a6a","https://git.kernel.org/stable/c/a60db84f772fc3a906c6c4072f9207579c41166f","https://git.kernel.org/stable/c/ac888d58869bb99753e7652be19a151df9ecb35d","https://git.kernel.org/stable/c/e3915f028b1f1c37e87542e5aadd33728c259d96","https://git.kernel.org/stable/c/eae7435b48ffc8e9be0ff9cfeae40af479a609dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42228 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_reloc Initialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001. V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian) | ["https://git.kernel.org/stable/c/3b505759447637dcccb50cbd98ec6f8d2a04fc46","https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef","https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944","https://git.kernel.org/stable/c/9ee1534ecdd5b4c013064663502d7fde824d2144","https://git.kernel.org/stable/c/d35cf41c8eb5d9fe95b21ae6ee2910f9ba4878e8","https://git.kernel.org/stable/c/da6a85d197888067e8d38b5d22c986b5b5cab712","https://git.kernel.org/stable/c/df02642c21c984303fe34c3f7d72965792fb1a15","https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440","https://git.kernel.org/stable/c/855ae72c20310e5402b2317fc537d911e87537ef","https://git.kernel.org/stable/c/88a9a467c548d0b3c7761b4fd54a68e70f9c0944","https://git.kernel.org/stable/c/f8f120b3de48b8b6bdf8988a9b334c2d61c17440"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42162 | High | N/A | In the Linux kernel, the following vulnerability has been resolved: gve: Account for stopped queues when reading NIC stats We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gve_get_ethtool_stats might make an invalid access on the priv->stats_report->stats array. | ["https://git.kernel.org/stable/c/32675d828c8a392e20d5b42375ed112c407e4b62","https://git.kernel.org/stable/c/af9bcf910b1f86244f39e15e701b2dc564b469a6","https://git.kernel.org/stable/c/32675d828c8a392e20d5b42375ed112c407e4b62","https://git.kernel.org/stable/c/af9bcf910b1f86244f39e15e701b2dc564b469a6"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36899 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpiolib: cdev: Fix use after free in lineinfo_changed_notify The use-after-free issue occurs as follows: when the GPIO chip device file is being closed by invoking gpio_chrdev_release(), watched_lines is freed by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier chain failed due to waiting write rwsem. Additionally, one of the GPIO chip's lines is also in the release process and holds the notifier chain's read rwsem. Consequently, a race condition leads to the use-after-free of watched_lines. Here is the typical stack when issue happened: [free] gpio_chrdev_release() --> bitmap_free(cdev->watched_lines) <-- freed --> blocking_notifier_chain_unregister() --> down_write(&nh->rwsem) <-- waiting rwsem --> __down_write_common() --> rwsem_down_write_slowpath() --> schedule_preempt_disabled() --> schedule() [use] st54spi_gpio_dev_release() --> gpio_free() --> gpiod_free() --> gpiod_free_commit() --> gpiod_line_state_notify() --> blocking_notifier_call_chain() --> down_read(&nh->rwsem); <-- held rwsem --> notifier_call_chain() --> lineinfo_changed_notify() --> test_bit(xxxx, cdev->watched_lines) <-- use after free The side effect of the use-after-free issue is that a GPIO line event is being generated for userspace where it shouldn't. However, since the chrdev is being closed, userspace won't have the chance to read that event anyway. To fix the issue, call the bitmap_free() function after the unregistration of lineinfo_changed_nb notifier chain. | ["https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da","https://git.kernel.org/stable/c/2d008d4961b039d2edce8976289773961b7e5fb5","https://git.kernel.org/stable/c/2dfbb920a89bdc58087672ad5325dc6c588b6860","https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a","https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239","https://git.kernel.org/stable/c/d38c49f7bdf14381270736299e2ff68ec248a017","https://git.kernel.org/stable/c/02f6b0e1ec7e0e7d059dddc893645816552039da","https://git.kernel.org/stable/c/95ca7c90eaf5ea8a8460536535101e3e81160e2a","https://git.kernel.org/stable/c/ca710b5f40b8b16fdcad50bebd47f50e4c62d239"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50286 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table. | ["https://git.kernel.org/stable/c/0a77715db22611df50b178374c51e2ba0d58866e","https://git.kernel.org/stable/c/e7a2ad2044377853cf8c59528dac808a08a99c72","https://git.kernel.org/stable/c/e923503a56b3385b64ae492e3225e4623f560c5b","https://git.kernel.org/stable/c/f56446ba5378d19e31040b548a14ee9a8f1500ea"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26984 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nouveau: fix instmem race condition around ptr stores Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. | ["https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716","https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7","https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52","https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572","https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525","https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039","https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9","https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce","https://git.kernel.org/stable/c/13d76b2f443dc371842916dd8768009ff1594716","https://git.kernel.org/stable/c/1bc4825d4c3ec6abe43cf06c3c39d664d044cbf7","https://git.kernel.org/stable/c/21ca9539f09360fd83654f78f2c361f2f5ddcb52","https://git.kernel.org/stable/c/3ab056814cd8ab84744c9a19ef51360b2271c572","https://git.kernel.org/stable/c/a019b44b1bc6ed224c46fb5f88a8a10dd116e525","https://git.kernel.org/stable/c/ad74d208f213c06d860916ad40f609ade8c13039","https://git.kernel.org/stable/c/bba8ec5e9b16649d85bc9e9086bf7ae5b5716ff9","https://git.kernel.org/stable/c/fff1386cc889d8fb4089d285f883f8cba62d82ce","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38589 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netrom: fix possible dead-lock in nr_rt_ioctl() syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated--- | ["https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691","https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7","https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5","https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3","https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5","https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de","https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d","https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6","https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8","https://git.kernel.org/stable/c/1fbfb483c1a290dce3f41f52d45cc46dd88b7691","https://git.kernel.org/stable/c/3db2fc45d1d2a6457f06ebdfd45b9820e5b5c2b7","https://git.kernel.org/stable/c/421c50fa81836775bf0fd6ce0e57a6eb27af24d5","https://git.kernel.org/stable/c/5bc50a705cfac8f64ce51c95611c3dd0554ef9c3","https://git.kernel.org/stable/c/5fb7e2a4335fc67d6952ad2a6613c46e0b05f7c5","https://git.kernel.org/stable/c/b117e5b4f27c2c9076561b6be450a9619f0b79de","https://git.kernel.org/stable/c/b9d663fbf74290cb68fbc66ae4367bd56837ad1d","https://git.kernel.org/stable/c/e03e7f20ebf7e1611d40d1fdc1bde900fd3335f6","https://git.kernel.org/stable/c/f28bdc2ee5d9300cc77bd3d97b5b3cdd14960fd8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42232 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: libceph: fix race between delayed_work() and ceph_monc_stop() The way the delayed work is handled in ceph_monc_stop() is prone to races with mon_fault() and possibly also finish_hunting(). Both of these can requeue the delayed work which wouldn't be canceled by any of the following code in case that happens after cancel_delayed_work_sync() runs -- __close_session() doesn't mess with the delayed work in order to avoid interfering with the hunting interval logic. This part was missed in commit b5d91704f53e ("libceph: behave in mon_fault() if cur_mon < 0") and use-after-free can still ensue on monc and objects that hang off of it, with monc->auth and monc->monmap being particularly susceptible to quickly being reused. To fix this: - clear monc->cur_mon and monc->hunting as part of closing the session in ceph_monc_stop() - bail from delayed_work() if monc->cur_mon is cleared, similar to how it's done in mon_fault() and finish_hunting() (based on monc->hunting) - call cancel_delayed_work_sync() after the session is closed | ["https://git.kernel.org/stable/c/1177afeca833174ba83504688eec898c6214f4bf","https://git.kernel.org/stable/c/20cf67dcb7db842f941eff1af6ee5e9dc41796d7","https://git.kernel.org/stable/c/2d33654d40a05afd91ab24c9a73ab512a0670a9a","https://git.kernel.org/stable/c/33d38c5da17f8db2d80e811b7829d2822c10625e","https://git.kernel.org/stable/c/34b76d1922e41da1fa73d43b764cddd82ac9733c","https://git.kernel.org/stable/c/63e5d035e3a7ab7412a008f202633c5e6a0a28ea","https://git.kernel.org/stable/c/69c7b2fe4c9cc1d3b1186d1c5606627ecf0de883","https://git.kernel.org/stable/c/9525af1f58f67df387768770fcf6d6a8f23aee3d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: only mark 'subflow' endp as available Adding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0) ... before decrementing the local_addr_used counter helped to find a bug when running the "remove single address" subtest from the mptcp_join.sh selftests. Removing a 'signal' endpoint will trigger the removal of all subflows linked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() with rm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_used counter, which is wrong in this case because this counter is linked to 'subflow' endpoints, and here it is a 'signal' endpoint that is being removed. Now, the counter is decremented, only if the ID is being used outside of mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, and if the ID is not 0 -- local_addr_used is not taking into account these ones. This marking of the ID as being available, and the decrement is done no matter if a subflow using this ID is currently available, because the subflow could have been closed before. | ["https://git.kernel.org/stable/c/322ea3778965da72862cca2a0c50253aacf65fe6","https://git.kernel.org/stable/c/43cf912b0b0fc7b4fd12cbc735d1f5afb8e1322d","https://git.kernel.org/stable/c/7fdc870d08960961408a44c569f20f50940e7d4f","https://git.kernel.org/stable/c/9849cfc67383ceb167155186f8f8fe8a896b60b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44995 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it. | ["https://git.kernel.org/stable/c/195918217448a6bb7f929d6a2ffffce9f1ece1cc","https://git.kernel.org/stable/c/67492d4d105c0a6321b00c393eec96b9a7a97a16","https://git.kernel.org/stable/c/6ae2b7d63cd056f363045eb65409143e16f23ae8","https://git.kernel.org/stable/c/be5e816d00a506719e9dbb1a9c861c5ced30a109","https://git.kernel.org/stable/c/de37408d5c26fc4a296a28a0c96dcb814219bfa1","https://git.kernel.org/stable/c/fa1d4de7265c370e673583ac8d1bd17d21826cd9","https://git.kernel.org/stable/c/fc250eca15bde34c4c8f806b9d88f55bd56a992c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48659 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/slub: fix to return errno if kmalloc() fails In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to out-of-memory, if it fails, return errno correctly rather than triggering panic via BUG_ON(); kernel BUG at mm/slub.c:5893! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Call trace: sysfs_slab_add+0x258/0x260 mm/slub.c:5973 __kmem_cache_create+0x60/0x118 mm/slub.c:4899 create_cache mm/slab_common.c:229 [inline] kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline] f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149 mount_bdev+0x1b8/0x210 fs/super.c:1400 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512 legacy_get_tree+0x30/0x74 fs/fs_context.c:610 vfs_get_tree+0x40/0x140 fs/super.c:1530 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040 path_mount+0x358/0x914 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568 | ["https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9","https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296","https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c","https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124","https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd","https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c","https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457","https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755","https://git.kernel.org/stable/c/016b150992eebc32c4a18f783cf2bb6e2545a3d9","https://git.kernel.org/stable/c/02bcd951aa3c2cea95fb241c20802e9501940296","https://git.kernel.org/stable/c/2d6e55e0c03804e1e227b80a5746e086d6c6696c","https://git.kernel.org/stable/c/379ac7905ff3f0a6a4e507d3e9f710ec4fab9124","https://git.kernel.org/stable/c/7e9c323c52b379d261a72dc7bd38120a761a93cd","https://git.kernel.org/stable/c/a1d83a19cec3bfeb2b3547a1f7631e432a766d1c","https://git.kernel.org/stable/c/e9219fa63c5c25804af82c7aa54d1ec770ebe457","https://git.kernel.org/stable/c/e996821717c5cf8aa1e1abdb6b3d900a231e3755"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39484 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mmc: davinci: Don't strip remove function when driver is builtin Using __exit for the remove function results in the remove callback being discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g. using sysfs or hotplug), the driver is just removed without the cleanup being performed. This results in resource leaks. Fix it by compiling in the remove callback unconditionally. This also fixes a W=1 modpost warning: WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in reference: davinci_mmcsd_driver+0x10 (section: .data) -> davinci_mmcsd_remove (section: .exit.text) | ["https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584","https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3","https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e","https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4","https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb","https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1","https://git.kernel.org/stable/c/1d5ed0efe51d36b9ae9b64f133bf41cdbf56f584","https://git.kernel.org/stable/c/55c421b364482b61c4c45313a535e61ed5ae4ea3","https://git.kernel.org/stable/c/5ee241f72edc6dce5051a5f100eab6cc019d873e","https://git.kernel.org/stable/c/6ff7cfa02baabec907f6f29ea76634e6256d2ec4","https://git.kernel.org/stable/c/7590da4c04dd4aa9c262da0231e978263861c6eb","https://git.kernel.org/stable/c/aea35157bb9b825faa0432bd0f7fbea37ff39aa1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40932 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/exynos/vidi: fix memory leak in .get_modes() The duplicated EDID is never freed. Fix it. | ["https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003","https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e","https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819","https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226","https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224","https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d","https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1","https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8","https://git.kernel.org/stable/c/0acc356da8546b5c55aabfc2e2c5caa0ac9b0003","https://git.kernel.org/stable/c/38e3825631b1f314b21e3ade00b5a4d737eb054e","https://git.kernel.org/stable/c/540ca99729e28dbe902b01039a3b4bd74520a819","https://git.kernel.org/stable/c/777838c9b571674ef14dbddf671f372265879226","https://git.kernel.org/stable/c/a269c5701244db2722ae0fce5d1854f5d8f31224","https://git.kernel.org/stable/c/cb3ac233434dba130281db330c4b15665b2d2c4d","https://git.kernel.org/stable/c/dcba6bedb439581145d8aa6b0925209f23184ae1","https://git.kernel.org/stable/c/ebcf81504fef03f701b9711e43fea4fe2d82ebc8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27043 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. | ["https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644","https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e","https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d","https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712","https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62","https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5","https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b","https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856","https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086","https://git.kernel.org/stable/c/096237039d00c839f3e3a5fe6d001bf0db45b644","https://git.kernel.org/stable/c/0d3fe80b6d175c220b3e252efc6c6777e700e98e","https://git.kernel.org/stable/c/35674111a043b0482a9bc69da8850a83f465b07d","https://git.kernel.org/stable/c/437a111f79a2f5b2a5f21e27fdec6f40c8768712","https://git.kernel.org/stable/c/779e8db7efb22316c8581d6c229636d2f5694a62","https://git.kernel.org/stable/c/8c64f4cdf4e6cc5682c52523713af8c39c94e6d5","https://git.kernel.org/stable/c/b7586e902128e4fb7bfbb661cb52e4215a65637b","https://git.kernel.org/stable/c/d0f5c28333822f9baa5280d813124920720fd856","https://git.kernel.org/stable/c/f20c3270f3ed5aa6919a87e4de9bf6c05fb57086","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48913 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blktrace: fix use after free for struct blk_trace When tracing the whole disk, 'dropped' and 'msg' will be created under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free() won't remove those files. What's worse, the following UAF can be triggered because of accessing stale 'dropped' and 'msg': ================================================================== BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100 Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188 CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_address_description.constprop.0.cold+0xab/0x381 ? blk_dropped_read+0x89/0x100 ? blk_dropped_read+0x89/0x100 kasan_report.cold+0x83/0xdf ? blk_dropped_read+0x89/0x100 kasan_check_range+0x140/0x1b0 blk_dropped_read+0x89/0x100 ? blk_create_buf_file_callback+0x20/0x20 ? kmem_cache_free+0xa1/0x500 ? do_sys_openat2+0x258/0x460 full_proxy_read+0x8f/0xc0 vfs_read+0xc6/0x260 ksys_read+0xb9/0x150 ? vfs_write+0x3d0/0x3d0 ? fpregs_assert_state_consistent+0x55/0x60 ? exit_to_user_mode_prepare+0x39/0x1e0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fbc080d92fd Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1 RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045 RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0 R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8 </TASK> Allocated by task 1050: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 do_blk_trace_setup+0xcb/0x410 __blk_trace_setup+0xac/0x130 blk_trace_ioctl+0xe9/0x1c0 blkdev_ioctl+0xf1/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 1050: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x103/0x180 kfree+0x9a/0x4c0 __blk_trace_remove+0x53/0x70 blk_trace_ioctl+0x199/0x1c0 blkdev_common_ioctl+0x5e9/0xb30 blkdev_ioctl+0x1a5/0x390 __x64_sys_ioctl+0xa5/0xe0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88816912f380 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 88 bytes inside of 96-byte region [ffff88816912f380, ffff88816912f3e0) The buggy address belongs to the page: page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780 raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc >ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ^ ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc ================================================================== | ["https://git.kernel.org/stable/c/30939293262eb433c960c4532a0d59c4073b2b84","https://git.kernel.org/stable/c/6418634238ade86f2b08192928787f39d8afb58c","https://git.kernel.org/stable/c/78acc7dbd84a8c173a08584750845c31611160f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57979 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pps: Fix a use-after-free On a board running ntpd and gpsd, I'm seeing a consistent use-after-free in sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- ...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exception This happens because pps_device_destruct() frees the pps_device with the embedded cdev immediately after calling cdev_del(), but, as the comment above cdev_del() notes, fops for previously opened cdevs are still callable even after cdev_del() returns. I think this bug has always been there: I can't explain why it suddenly started happening every time I reboot this particular board. In commit d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source."), George Spelvin suggested removing the embedded cdev. That seems like the simplest way to fix this, so I've implemented his suggestion, using __register_chrdev() with pps_idr becoming the source of truth for which minor corresponds to which device. But now that pps_idr defines userspace visibility instead of cdev_add(), we need to be sure the pps->dev refcount can't reach zero while userspace can still find it again. So, the idr_remove() call moves to pps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1 | ["https://git.kernel.org/stable/c/1a7735ab2cb9747518a7416fb5929e85442dec62","https://git.kernel.org/stable/c/785c78ed0d39d1717cca3ef931d3e51337b5e90e","https://git.kernel.org/stable/c/7e5ee3281dc09014367f5112b6d566ba36ea2d49","https://git.kernel.org/stable/c/85241f7de216f8298f6e48540ea13d7dcd100870","https://git.kernel.org/stable/c/91932db1d96b2952299ce30c1c693d834d10ace6","https://git.kernel.org/stable/c/c4041b6b0a7a3def8cf3f3d6120ff337bc4c40f7","https://git.kernel.org/stable/c/c79a39dc8d060b9e64e8b0fa9d245d44befeefbe","https://git.kernel.org/stable/c/cd3bbcb6b3a7caa5ce67de76723b6d8531fb7f64"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46814 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check msg_id before processing transcation [WHY & HOW] HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid array index, and it needs checking before used. This fixes 4 OVERRUN issues reported by Coverity. | ["https://git.kernel.org/stable/c/0147505f08220c89b3a9c90eb608191276e263a8","https://git.kernel.org/stable/c/6590643c5de74098d27933b7d224d5ac065d7755","https://git.kernel.org/stable/c/916083054670060023d3f8a8ace895d710e268f4","https://git.kernel.org/stable/c/cb63090a17d3abb87f132851fa3711281249b7d2","https://git.kernel.org/stable/c/fa71face755e27dc44bc296416ebdf2c67163316","https://git.kernel.org/stable/c/fe63daf7b10253b0faaa60c55d6153cd276927aa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46818 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check gpio_id before used as array index [WHY & HOW] GPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore should be checked in advance. This fixes 5 OVERRUN issues reported by Coverity. | ["https://git.kernel.org/stable/c/0184cca30cad74d88f5c875d4e26999e26325700","https://git.kernel.org/stable/c/08e7755f754e3d2cef7d3a7da538d33526bd6f7c","https://git.kernel.org/stable/c/276e3fd93e3beb5894eb1cc8480f9f417d51524d","https://git.kernel.org/stable/c/2a5626eeb3b5eec7a36886f9556113dd93ec8ed6","https://git.kernel.org/stable/c/3d4198ab612ad48f73383ad3bb5663e6f0cdf406","https://git.kernel.org/stable/c/40c2e8bc117cab8bca8814735f28a8b121654a84","https://git.kernel.org/stable/c/8520fdc8ecc38f240a8e9e7af89cca6739c3e790"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46821 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix negative array index read Avoid using the negative values for clk_idex as an index into an array pptable->DpmDescriptor. V2: fix clk_index return check (Tim Huang) | ["https://git.kernel.org/stable/c/06a3810010b525b9958424e344f0c25b09e128fa","https://git.kernel.org/stable/c/4711b1347cb9f0c3083da6d87c624d75f9bd1d50","https://git.kernel.org/stable/c/60f4a4bc3329e5cb8c4df0cc961f0d5ffd96e22d","https://git.kernel.org/stable/c/befd1dc693c98bad69a701ede3a298698f0f9436","https://git.kernel.org/stable/c/c8c19ebf7c0b202a6a2d37a52ca112432723db5f","https://git.kernel.org/stable/c/e549cd6da1f21c34ba0f65adeca6a8aa9860b381"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26934 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: core: Fix deadlock in usb_deauthorize_interface() Among the attribute file callback routines in drivers/usb/core/sysfs.c, the interface_authorized_store() function is the only one which acquires a device lock on an ancestor device: It calls usb_deauthorize_interface(), which locks the interface's parent USB device. The will lead to deadlock if another process already owns that lock and tries to remove the interface, whether through a configuration change or because the device has been disconnected. As part of the removal procedure, device_del() waits for all ongoing sysfs attribute callbacks to complete. But usb_deauthorize_interface() can't complete until the device lock has been released, and the lock won't be released until the removal has finished. The mechanism provided by sysfs to prevent this kind of deadlock is to use the sysfs_break_active_protection() function, which tells sysfs not to wait for the attribute callback. Reported-and-tested by: Yue Sun <samsun1006219@gmail.com> Reported by: xingwei lee <xrivendell7@gmail.com> | ["https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6","https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384","https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947","https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a","https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5","https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f","https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5","https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057","https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9","https://git.kernel.org/stable/c/07acf979da33c721357ff27129edf74c23c036c6","https://git.kernel.org/stable/c/122a06f1068bf5e39089863f4f60b1f5d4273384","https://git.kernel.org/stable/c/12d6a5681a0a5cecc2af7860f0a1613fa7c6e947","https://git.kernel.org/stable/c/1b175bc579f46520b11ecda443bcd2ee4904f66a","https://git.kernel.org/stable/c/80ba43e9f799cbdd83842fc27db667289b3150f5","https://git.kernel.org/stable/c/8cbdd324b41528994027128207fae8100dff094f","https://git.kernel.org/stable/c/ab062fa3dc69aea88fe62162c5881ba14b50ecc5","https://git.kernel.org/stable/c/dbdf66250d2d33e8b27352fcb901de79f3521057","https://git.kernel.org/stable/c/e451709573f8be904a8a72d0775bf114d7c291d9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50264 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL. | ["https://git.kernel.org/stable/c/2a6a4e69f255b7aed17f93995691ab4f0d3c2203","https://git.kernel.org/stable/c/44d29897eafd0e1196453d3003a4d5e0b968eeab","https://git.kernel.org/stable/c/5f092a4271f6dccf88fe0d132475a17b69ef71df","https://git.kernel.org/stable/c/5f970935d09934222fdef3d0e20c648ea7a963c1","https://git.kernel.org/stable/c/6ca575374dd9a507cdd16dfa0e78c2e9e20bd05f","https://git.kernel.org/stable/c/b110196fec44fe966952004bd426967c2a8fd358","https://git.kernel.org/stable/c/eb1bdcb7dfc30b24495ee4c5533af0ed135cb5f1","https://git.kernel.org/stable/c/fd8ae346692a56b4437d626c5460c7104980f389"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49577 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udp: Fix a data-race around sysctl_udp_l3mdev_accept. While reading sysctl_udp_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/3d72bb4188c708bb16758c60822fc4dda7a95174","https://git.kernel.org/stable/c/3f2ac2d6511bb0652abf4d7388d65bb9ff1c641c","https://git.kernel.org/stable/c/cb0d28934ca10f99c47e2c6f451405d6c954fe48","https://git.kernel.org/stable/c/f39b03bd727a8fea62e82f10fe2e0d753b9930ff","https://git.kernel.org/stable/c/fcaef69c79ec222e55643e666b80b221e70fa6a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49580 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_multipath_use_neigh. While reading sysctl_fib_multipath_use_neigh, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/14e996577ed2799a1ed6ffeb71c76d63acb28444","https://git.kernel.org/stable/c/6727f39e99e0f545d815edebb6c94228485427ec","https://git.kernel.org/stable/c/87507bcb4f5de16bb419e9509d874f4db6c0ad0f","https://git.kernel.org/stable/c/b8d345db03b4deffb4f04219a51d3b1e94171b76","https://git.kernel.org/stable/c/e045d672ba06e1d35bacb56374d350de0ac99066"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49594 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor. While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/033963b220633ed1602d458e7e4ac06afa9fefb2","https://git.kernel.org/stable/c/8e92d4423615a5257d0d871fc067aa561f597deb","https://git.kernel.org/stable/c/cc36c37f5fe066c4708e623ead96dc8f57224bf5","https://git.kernel.org/stable/c/d5bece4df6090395f891110ef52a6f82d16685db","https://git.kernel.org/stable/c/e2ecbf3f0aa88277d43908c53b99399d55729ff9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2017-1000255 | Medium | N/A | On Linux running on PowerPC hardware (Power8 or later) a user process can craft a signal frame and then do a sigreturn so that the kernel will take an exception (interrupt), and use the r1 value *from the signal frame* as the kernel stack pointer. As part of the exception entry the content of the signal frame is written to the kernel stack, allowing an attacker to overwrite arbitrary locations with arbitrary values. The exception handling does produce an oops, and a panic if panic_on_oops=1, but only after kernel memory has been over written. This flaw was introduced in commit: "5d176f751ee3 (powerpc: tm: Enable transactional memory (TM) lazily for userspace)" which was merged upstream into v4.9-rc1. Please note that kernels built with CONFIG_PPC_TRANSACTIONAL_MEM=n are not vulnerable. | ["http://www.securityfocus.com/bid/101264","https://access.redhat.com/errata/RHSA-2018:0654","https://access.redhat.com/security/cve/CVE-2017-1000255","http://www.securityfocus.com/bid/101264","https://access.redhat.com/errata/RHSA-2018:0654","https://access.redhat.com/security/cve/CVE-2017-1000255"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49934 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable. | ["https://git.kernel.org/stable/c/1a4159138e718db6199f0abf376ad52f726dcc5c","https://git.kernel.org/stable/c/7f7b850689ac06a62befe26e1fd1806799e7f152","https://git.kernel.org/stable/c/e0f6ee75f50476607ca82fc7c3711c795ce09b52","https://git.kernel.org/stable/c/ef921bc72328b577cb45772ff7921cba4773b74a","https://git.kernel.org/stable/c/f92b8829c6e75632de4e2b9f70e7a7e6c5c2ba98"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49861 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via *<ptr> = val. The .arg*_size has been initialized reflecting the actual sizeof(*<ptr>). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write *<ptr> = val. | ["https://git.kernel.org/stable/c/1e75d25133158b525e0456876e9bcfd6b2993fd5","https://git.kernel.org/stable/c/2ed98ee02d1e08afee88f54baec39ea78dc8a23c","https://git.kernel.org/stable/c/32556ce93bc45c730829083cb60f95a2728ea48b","https://git.kernel.org/stable/c/988e55abcf7fdb8fc9a76a7cf3f4e939a4d4fb3a","https://git.kernel.org/stable/c/a2c8dc7e21803257e762b0bf067fd13e9c995da0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47757 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case. | ["https://git.kernel.org/stable/c/257f9e5185eb6de83377caea686c306e22e871f2","https://git.kernel.org/stable/c/a33e967b681e088a125b979975c93e3453e686cd","https://git.kernel.org/stable/c/a8abfda768b9f33630cfbc4af6c4214f1e5681b0","https://git.kernel.org/stable/c/c4cbcc64bb31e67e02940ce060cc77f7180564cf","https://git.kernel.org/stable/c/c4f8554996e8ada3be872dfb8f60e93bcf15fb27","https://git.kernel.org/stable/c/d20674f31626e0596ae4c1d9401dfb6739b81b58","https://git.kernel.org/stable/c/ed76d381dae125b81d09934e365391a656249da8","https://git.kernel.org/stable/c/f3a9859767c7aea758976f5523903d247e585129","https://git.kernel.org/stable/c/f9c96351aa6718b42a9f42eaf7adce0356bdb5e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49860 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory. | ["https://git.kernel.org/stable/c/0cdfb9178a3bba843c95c2117c82c15f1a64b9ce","https://git.kernel.org/stable/c/2364b6af90c6b6d8a4783e0d3481ca80af699554","https://git.kernel.org/stable/c/4b081991c4363e072e1748efed0bbec8a77daba5","https://git.kernel.org/stable/c/4bb1e7d027413835b086aed35bc3f0713bc0f72b","https://git.kernel.org/stable/c/5c8d007c14aefc3f2ddf71e4c40713733dc827be","https://git.kernel.org/stable/c/92fd5209fc014405f63a7db79802ca4b01dc0c05","https://git.kernel.org/stable/c/f0921ecd4ddc14646bb5511f49db4d7d3b0829f0","https://git.kernel.org/stable/c/f51e5a88f2e7224858b261546cf6b3037dfb1323","https://git.kernel.org/stable/c/f51f711d36e61fbb87c67b524fd200e05172668d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48871 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer Driver's probe allocates memory for RX FIFO (port->rx_fifo) based on default RX FIFO depth, e.g. 16. Later during serial startup the qcom_geni_serial_port_setup() updates the RX FIFO depth (port->rx_fifo_depth) to match real device capabilities, e.g. to 32. The RX UART handle code will read "port->rx_fifo_depth" number of words into "port->rx_fifo" buffer, thus exceeding the bounds. This can be observed in certain configurations with Qualcomm Bluetooth HCI UART device and KASAN: Bluetooth: hci0: QCA Product ID :0x00000010 Bluetooth: hci0: QCA SOC Version :0x400a0200 Bluetooth: hci0: QCA ROM Version :0x00000200 Bluetooth: hci0: QCA Patch Version:0x00000d2b Bluetooth: hci0: QCA controller version 0x02000200 Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2 Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2) Bluetooth: hci0: QCA Failed to download patch (-2) ================================================================== BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c Write of size 4 at addr ffff279347d578c0 by task swapper/0/0 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x40 dump_stack_lvl+0x8c/0xb8 print_report+0x188/0x488 kasan_report+0xb4/0x100 __asan_store4+0x80/0xa4 handle_rx_uart+0xa8/0x18c qcom_geni_serial_handle_rx+0x84/0x9c qcom_geni_serial_isr+0x24c/0x760 __handle_irq_event_percpu+0x108/0x500 handle_irq_event+0x6c/0x110 handle_fasteoi_irq+0x138/0x2cc generic_handle_domain_irq+0x48/0x64 If the RX FIFO depth changes after probe, be sure to resize the buffer. | ["https://git.kernel.org/stable/c/894681682dbefdad917b88f86cde1069140a047a","https://git.kernel.org/stable/c/b8caf69a6946e18ffebad49847e258f5b6d52ac2","https://git.kernel.org/stable/c/cb53a3366eb28fed67850c80afa52075bb71a38a","https://git.kernel.org/stable/c/fd524ca7fe45b8a06dca2dd546d62684a9768f95"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52904 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate() The subs function argument may be NULL, so do not use it before the NULL check. | ["https://git.kernel.org/stable/c/92a9c0ad86d47ff4cce899012e355c400f02cfb8","https://git.kernel.org/stable/c/a474d4ad59cd4642d1b7e3a6c08cef9eca0992c8","https://git.kernel.org/stable/c/f57204edc10760c935d8d36ea999dc8acf018030"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49027 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix error handling in iavf_init_module() The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak") | ["https://git.kernel.org/stable/c/0d9f5bd54b913018031c5b964fc1f9a31f5f6cb5","https://git.kernel.org/stable/c/227d8d2f7f2278b8468c5531b0cd0f2a905b4486","https://git.kernel.org/stable/c/971c55f0763b480e63ceb7a22beb19be2509e5ed","https://git.kernel.org/stable/c/bd477b891a4fa084561234eed4afacb3001dd359"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vdpa: fix use-after-free on vp_vdpa_remove When vp_vdpa driver is unbind, vp_vdpa is freed in vdpa_unregister_device and then vp_vdpa->mdev.pci_dev is dereferenced in vp_modern_remove, triggering use-after-free. Call Trace of unbinding driver free vp_vdpa : do_syscall_64 vfs_write kernfs_fop_write_iter device_release_driver_internal pci_device_remove vp_vdpa_remove vdpa_unregister_device kobject_release device_release kfree Call Trace of dereference vp_vdpa->mdev.pci_dev: vp_modern_remove pci_release_selected_regions pci_release_region pci_resource_len pci_resource_end (dev)->resource[(bar)].end | ["https://git.kernel.org/stable/c/4b1743bc715a3691a63ac21b349079b07bf1b19e","https://git.kernel.org/stable/c/dc54ba9932aeaaa1a21fe214af1f446593a78274","https://git.kernel.org/stable/c/eb057b44dbe35ae14527830236a92f51de8f9184","https://git.kernel.org/stable/c/4b1743bc715a3691a63ac21b349079b07bf1b19e","https://git.kernel.org/stable/c/dc54ba9932aeaaa1a21fe214af1f446593a78274","https://git.kernel.org/stable/c/eb057b44dbe35ae14527830236a92f51de8f9184"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40959 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr() ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly. syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64 Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00 RSP: 0018:ffffc90000117378 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7 RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98 RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000 R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 | ["https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1","https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf","https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a","https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08","https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7","https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3","https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164","https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41","https://git.kernel.org/stable/c/20427b85781aca0ad072851f6907a3d4b2fed8d1","https://git.kernel.org/stable/c/600a62b4232ac027f788c3ca395bc2333adeaacf","https://git.kernel.org/stable/c/83c02fb2cc0afee5bb53cddf3f34f045f654ad6a","https://git.kernel.org/stable/c/9f30f1f1a51d91e19f5a09236bb0b59e6a07ad08","https://git.kernel.org/stable/c/c71761292d4d002a8eccb57b86792c4e3b3eb3c7","https://git.kernel.org/stable/c/caf0bec84c62fb1cf6f7c9f0e8c857c87f8adbc3","https://git.kernel.org/stable/c/d46401052c2d5614da8efea5788532f0401cb164","https://git.kernel.org/stable/c/f897d7171652fcfc76d042bfec798b010ee89e41"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40960 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: prevent possible NULL dereference in rt6_probe() syzbot caught a NULL dereference in rt6_probe() [1] Bail out if __in6_dev_get() returns NULL. [1] Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f] CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline] RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758 Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19 RSP: 0018:ffffc900034af070 EFLAGS: 00010203 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000 RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000 FS: 00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784 nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496 __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825 find_rr_leaf net/ipv6/route.c:853 [inline] rt6_select net/ipv6/route.c:897 [inline] fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195 ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231 pol_lookup_func include/net/ip6_fib.h:616 [inline] fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121 ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline] ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651 ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147 ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250 rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898 inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x4b8/0x5c0 net/socket.c:1160 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x6b6/0x1140 fs/read_write.c:590 ksys_write+0x1f8/0x260 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc","https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2","https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0","https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b","https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6","https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37","https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7","https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e","https://git.kernel.org/stable/c/1ed9849fdf9a1a617129346b11d2094ca26828dc","https://git.kernel.org/stable/c/51ee2f7c30790799d0ec30c0ce0c743e58f046f2","https://git.kernel.org/stable/c/569c9d9ea6648d099187527b93982f406ddcebc0","https://git.kernel.org/stable/c/6eed6d3cd19ff3cfa83aeceed86da14abaf7417b","https://git.kernel.org/stable/c/73e7c8ca6ad76f29b2c99c20845a6f3b203ff0c6","https://git.kernel.org/stable/c/b86762dbe19a62e785c189f313cda5b989931f37","https://git.kernel.org/stable/c/d66fc4826127c82f99c4033380f8e93833d331c7","https://git.kernel.org/stable/c/f0cda984e4e634b221dbf9642b8ecc5b4806b41e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35973 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: geneve: fix header validation in geneve[6]_xmit_skb syzbot is able to trigger an uninit-value in geneve_xmit() [1] Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield()) uses skb_protocol(skb, true), pskb_inet_may_pull() is only using skb->protocol. If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol, pskb_inet_may_pull() does nothing at all. If a vlan tag was provided by the caller (af_packet in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected. Add skb_vlan_inet_prepare() to perform a complete mac validation. Use this in geneve for the moment, I suspect we need to adopt this more broadly. v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types. v2,v3 - Addressed Sabrina comments on v1 and v2 [1] BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 | ["https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915","https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e","https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852","https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79","https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536","https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670","https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c","https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef","https://git.kernel.org/stable/c/10204df9beda4978bd1d0c2db0d8375bfb03b915","https://git.kernel.org/stable/c/190d9efa5773f26d6f334b1b8be282c4fa13fd5e","https://git.kernel.org/stable/c/357163fff3a6e48fe74745425a32071ec9caf852","https://git.kernel.org/stable/c/3c1ae6de74e3d2d6333d29a2d3e13e6094596c79","https://git.kernel.org/stable/c/43be590456e1f3566054ce78ae2dbb68cbe1a536","https://git.kernel.org/stable/c/4a1b65d1e55d53b397cb27014208be1e04172670","https://git.kernel.org/stable/c/d3adf11d7993518a39bd02b383cfe657ccc0023c","https://git.kernel.org/stable/c/d8a6213d70accb403b82924a1c229e733433a5ef","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50271 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top of ucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior. | ["https://git.kernel.org/stable/c/012f4d5d25e9ef92ee129bd5aa7aa60f692681e1","https://git.kernel.org/stable/c/0208ea17a1e4456fbfe555f13ae5c28f3d671e40","https://git.kernel.org/stable/c/4877d9b2a2ebad3ae240127aaa4cb8258b145cf7","https://git.kernel.org/stable/c/9e05e5c7ee8758141d2db7e8fea2cab34500c6ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43856 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma: fix call order in dmam_free_coherent dmam_free_coherent() frees a DMA allocation, which makes the freed vaddr available for reuse, then calls devres_destroy() to remove and free the data structure used to track the DMA allocation. Between the two calls, it is possible for a concurrent task to make an allocation with the same vaddr and add it to the devres list. If this happens, there will be two entries in the devres list with the same vaddr and devres_destroy() can free the wrong entry, triggering the WARN_ON() in dmam_match. Fix by destroying the devres entry before freeing the DMA allocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03 | ["https://git.kernel.org/stable/c/1fe97f68fce1ba24bf823bfb0eb0956003473130","https://git.kernel.org/stable/c/22094f5f52e7bc16c5bf9613365049383650b02e","https://git.kernel.org/stable/c/257193083e8f43907e99ea633820fc2b3bcd24c7","https://git.kernel.org/stable/c/28e8b7406d3a1f5329a03aa25a43aa28e087cb20","https://git.kernel.org/stable/c/2f7bbdc744f2e7051d1cb47c8e082162df1923c9","https://git.kernel.org/stable/c/87b34c8c94e29fa01d744e5147697f592998d954","https://git.kernel.org/stable/c/f993a4baf6b622232e4c190d34c220179e5d61eb","https://git.kernel.org/stable/c/fe2d246080f035e0af5793cb79067ba125e4fb63"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-5197 | Medium | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free. We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325. | ["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://kernel.dance/f15f29fd4779be8a418b66e9d52979bb6d6c2325","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49576 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_fields. While reading sysctl_fib_multipath_hash_fields, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/36f5b86f309b3b11295d087cd7433f1c897caf94","https://git.kernel.org/stable/c/548d6678c4a3d43667e59686665f8674b82440a3","https://git.kernel.org/stable/c/8895a9c2ac76fb9d3922fed4fe092c8ec5e5cccc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49588 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_migrate_req. While reading sysctl_tcp_migrate_req, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/4177f545895b1da08447a80692f30617154efa6e","https://git.kernel.org/stable/c/6e569a11eea20a1ccebc3c4e6366bf0574a449e1","https://git.kernel.org/stable/c/fcf6c6d8aeffebca66f37b17ef1b57112e5e09c1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49600 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_ip_autobind_reuse. While reading sysctl_ip_autobind_reuse, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/0db232765887d9807df8bcb7b6f29b2871539eab","https://git.kernel.org/stable/c/611ba70e5aca252ef43374dda97ed4cf1c47a07c","https://git.kernel.org/stable/c/87ceaa199a72c5856d49a030941fabcd5c3928d4","https://git.kernel.org/stable/c/fa7cdcf9b28d13aac1eeb34b948db8a18e041341"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49603 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_update_priority. While reading sysctl_ip_fwd_update_priority, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/11038fa781ab916535c53351537b22d6d405667d","https://git.kernel.org/stable/c/351f81f7d7185d18a9ff76f8f8c2fa8c4eea563b","https://git.kernel.org/stable/c/7bf9e18d9a5e99e3c83482973557e9f047b051e7","https://git.kernel.org/stable/c/bcc03369d3277ae075ed421f0c8bf4adb5e65b74"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26974 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - resolve race condition during AER recovery During the PCI AER system's error recovery process, the kernel driver may encounter a race condition with freeing the reset_data structure's memory. If the device restart will take more than 10 seconds the function scheduling that restart will exit due to a timeout, and the reset_data structure will be freed. However, this data structure is used for completion notification after the restart is completed, which leads to a UAF bug. This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340 To resolve this race condition, the memory associated to the container of the work_struct is freed on the worker if the timeout expired, otherwise on the function that schedules the worker. The timeout detection can be done by checking if the caller is still waiting for completion or not by using completion_done() function. | ["https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be","https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7","https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f","https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c","https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc","https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81","https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828","https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71","https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7","https://git.kernel.org/stable/c/0c2cf5142bfb634c0ef0a1a69cdf37950747d0be","https://git.kernel.org/stable/c/226fc408c5fcd23cc4186f05ea3a09a7a9aef2f7","https://git.kernel.org/stable/c/4ae5a97781ce7d6ecc9c7055396535815b64ca4f","https://git.kernel.org/stable/c/7d42e097607c4d246d99225bf2b195b6167a210c","https://git.kernel.org/stable/c/8a5a7611ccc7b1fba8d933a9f22a2e76859d94dc","https://git.kernel.org/stable/c/8e81cd58aee14a470891733181a47d123193ba81","https://git.kernel.org/stable/c/bb279ead42263e9fb09480f02a4247b2c287d828","https://git.kernel.org/stable/c/d03092550f526a79cf1ade7f0dfa74906f39eb71","https://git.kernel.org/stable/c/daba62d9eeddcc5b1081be7d348ca836c83c59d7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48872 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: misc: fastrpc: Fix use-after-free race condition for maps It is possible that in between calling fastrpc_map_get() until map->fl->lock is taken in fastrpc_free_map(), another thread can call fastrpc_map_lookup() and get a reference to a map that is about to be deleted. Rewrite fastrpc_map_get() to only increase the reference count of a map if it's non-zero. Propagate this to callers so they can know if a map is about to be deleted. Fixes this warning: refcount_t: addition on 0; use-after-free. WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate ... Call trace: refcount_warn_saturate [fastrpc_map_get inlined] [fastrpc_map_lookup inlined] fastrpc_map_create fastrpc_internal_invoke fastrpc_device_ioctl __arm64_sys_ioctl invoke_syscall | ["https://git.kernel.org/stable/c/079c78c68714f7d8d58e66c477b0243b31806907","https://git.kernel.org/stable/c/556dfdb226ce1e5231d8836159b23f8bb0395bf4","https://git.kernel.org/stable/c/61a0890cb95afec5c8a2f4a879de2b6220984ef1","https://git.kernel.org/stable/c/96b328d119eca7563c1edcc4e1039a62e6370ecb","https://git.kernel.org/stable/c/b171d0d2cf1b8387c72c8d325c5d5746fa271e39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47747 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove. | ["https://git.kernel.org/stable/c/1c57d61a43293252ad732007c7070fdb112545fd","https://git.kernel.org/stable/c/25d559ed2beec9b34045886100dac46d1ad92eba","https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353","https://git.kernel.org/stable/c/516dbc6d16637430808c39568cbb6b841d32b55b","https://git.kernel.org/stable/c/77a77331cef0a219b8dd91361435eeef04cb741c","https://git.kernel.org/stable/c/822c7bb1f6f8b0331e8d1927151faf8db3b33afd","https://git.kernel.org/stable/c/b5109b60ee4fcb2f2bb24f589575e10cc5283ad4","https://git.kernel.org/stable/c/b5a84b6c772564c8359a9a0fbaeb2a2944aa1ee9","https://git.kernel.org/stable/c/d2abc379071881798d20e2ac1d332ad855ae22f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56619 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry() Syzbot reported that when searching for records in a directory where the inode's i_size is corrupted and has a large value, memory access outside the folio/page range may occur, or a use-after-free bug may be detected if KASAN is enabled. This is because nilfs_last_byte(), which is called by nilfs_find_entry() and others to calculate the number of valid bytes of directory data in a page from i_size and the page index, loses the upper 32 bits of the 64-bit size information due to an inappropriate type of local variable to which the i_size value is assigned. This caused a large byte offset value due to underflow in the end address calculation in the calling nilfs_find_entry(), resulting in memory access that exceeds the folio/page size. Fix this issue by changing the type of the local variable causing the bit loss from "unsigned int" to "u64". The return value of nilfs_last_byte() is also of type "unsigned int", but it is truncated so as not to exceed PAGE_SIZE and no bit loss occurs, so no change is required. | ["https://git.kernel.org/stable/c/09d6d05579fd46e61abf6e457bb100ff11f3a9d3","https://git.kernel.org/stable/c/31f7b57a77d4c82a34ddcb6ff35b5aa577ef153e","https://git.kernel.org/stable/c/48eb6e7404948032bbe811c5affbe39f6b316951","https://git.kernel.org/stable/c/5af8366625182f01f6d8465c9a3210574673af57","https://git.kernel.org/stable/c/985ebec4ab0a28bb5910c3b1481a40fbf7f9e61d","https://git.kernel.org/stable/c/c3afea07477baccdbdec4483f8d5e59d42a3f67f","https://git.kernel.org/stable/c/e3732102a9d638d8627d14fdf7b208462f0520e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56775 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix handling of plane refcount [Why] The mechanism to backup and restore plane states doesn't maintain refcount, which can cause issues if the refcount of the plane changes in between backup and restore operations, such as memory leaks if the refcount was supposed to go down, or double frees / invalid memory accesses if the refcount was supposed to go up. [How] Cache and re-apply current refcount when restoring plane states. | ["https://git.kernel.org/stable/c/27227a234c1487cb7a684615f0749c455218833a","https://git.kernel.org/stable/c/8cb2f6793845f135b28361ba8e96901cae3e5790"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53068 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | ["https://git.kernel.org/stable/c/15b17bbcea07d49c43d21aa700485cbd9f9d00d8","https://git.kernel.org/stable/c/1e1f523b185a8ccdcba625b31ff0312d052900e2","https://git.kernel.org/stable/c/295416091e44806760ccf753aeafdafc0ae268f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53095 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler()."). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated--- | ["https://git.kernel.org/stable/c/c7f9282fc27fc36dbaffc8527c723de264a132f8","https://git.kernel.org/stable/c/e8c71494181153a134c96da28766a57bd1eac8cb","https://git.kernel.org/stable/c/ef7134c7fc48e1441b398e55a862232868a6f0a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46702 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Mark XDomain as unplugged when router is removed I noticed that when we do discrete host router NVM upgrade and it gets hot-removed from the PCIe side as a result of NVM firmware authentication, if there is another host connected with enabled paths we hang in tearing them down. This is due to fact that the Thunderbolt networking driver also tries to cleanup the paths and ends up blocking in tb_disconnect_xdomain_paths() waiting for the domain lock. However, at this point we already cleaned the paths in tb_stop() so there is really no need for tb_disconnect_xdomain_paths() to do that anymore. Furthermore it already checks if the XDomain is unplugged and bails out early so take advantage of that and mark the XDomain as unplugged when we remove the parent router. | ["https://git.kernel.org/stable/c/18b3ad2a3cc877dd4b16f48d84aa27b78d53bf1d","https://git.kernel.org/stable/c/23ce6ba3b95488a2b9e9f6d43b340da0c15395dc","https://git.kernel.org/stable/c/747bc154577de6e6af4bc99abfa859b8419bb4d8","https://git.kernel.org/stable/c/7ca24cf9163c112bb6b580c6fb57c04a1f8b76e1","https://git.kernel.org/stable/c/80ac8d194831eca0c2f4fd862f7925532fda320c","https://git.kernel.org/stable/c/e2006140ad2e01a02ed0aff49cc2ae3ceeb11f8d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44958 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/smt: Fix unbalance sched_smt_present dec/inc I got the following warn report while doing stress test: jump label: negative count! WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0 Call Trace: <TASK> __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 </TASK> Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(), the cpu offline failed, but sched_smt_present is decremented before calling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so fix it by incrementing sched_smt_present in the error path. | ["https://git.kernel.org/stable/c/2a3548c7ef2e135aee40e7e5e44e7d11b893e7c4","https://git.kernel.org/stable/c/2cf7665efe451e48d27953e6b5bc627d518c902b","https://git.kernel.org/stable/c/65727331b60197b742089855ac09464c22b96f66","https://git.kernel.org/stable/c/d0c87a3c6be10a57aa3463c32c3fc6b2a47c3dab","https://git.kernel.org/stable/c/e22f910a26cc2a3ac9c66b8e935ef2a7dd881117"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40912 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup() The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150 Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise on the same CPU that is holding the lock. | ["https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932","https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e","https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81","https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485","https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb","https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f","https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e","https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc","https://git.kernel.org/stable/c/28ba44d680a30c51cf485a2f5a3b680e66ed3932","https://git.kernel.org/stable/c/44c06bbde6443de206b30f513100b5670b23fc5e","https://git.kernel.org/stable/c/456bbb8a31e425177dc0e8d4f98728a560c20e81","https://git.kernel.org/stable/c/47d176755d5c0baf284eff039560f8c1ba0ea485","https://git.kernel.org/stable/c/9c49b58b9a2bed707e7638576e54c4bccd97b9eb","https://git.kernel.org/stable/c/d90bdff79f8e40adf889b5408bfcf521528b169f","https://git.kernel.org/stable/c/e51637e0c66a6f72d134d9f95daa47ea62b43c7e","https://git.kernel.org/stable/c/e7e916d693dcb5a297f40312600a82475f2e63bc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gt: Cleanup partial engine discovery failures If we abort driver initialisation in the middle of gt/engine discovery, some engines will be fully setup and some not. Those incompletely setup engines only have 'engine->release == NULL' and so will leak any of the common objects allocated. v2: - Drop the destroy_pinned_context() helper for now. It's not really worth it with just a single callsite at the moment. (Janusz) | ["https://git.kernel.org/stable/c/5c855bcc730656c4b7d30aaddcd0eafc7003e112","https://git.kernel.org/stable/c/78350c36fb15afef423404a83dcbc5c558dce795","https://git.kernel.org/stable/c/78a033433a5ae4fee85511ee075bc9a48312c79e","https://git.kernel.org/stable/c/7d21587d35bc816c85a51b8686f0f7e8e676fb14"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40977 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921s: fix potential hung tasks during chip recovery During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery. | ["https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08","https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02","https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9","https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366","https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08","https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02","https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9","https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49727 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in l2tp_ip6_sendmsg When len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will be overflow. To fix, we can follow what udpv6 does and subtract the transhdrlen from the max. | ["https://git.kernel.org/stable/c/034246122f5c5e2e2a0b9fe04e24517920e9beb1","https://git.kernel.org/stable/c/0e818d433fc2718fe4da044ffca7431812a7e04e","https://git.kernel.org/stable/c/27a37755ceb401111ded76810359d3adc4b268a1","https://git.kernel.org/stable/c/2cf73c7cb6125083408d77f43d0e84d86aed0000","https://git.kernel.org/stable/c/2f42389d270f2304c8855b0b63498a5a4d0c053d","https://git.kernel.org/stable/c/6c4e3486d21173d60925ef52e512cae727b43d30","https://git.kernel.org/stable/c/b8879ca1fd7348b4d5db7db86dcb97f60c73d751","https://git.kernel.org/stable/c/f638a84afef3dfe10554c51820c16e39a278c915"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49731 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ata: libata-core: fix NULL pointer deref in ata_host_alloc_pinfo() In an unlikely (and probably wrong?) case that the 'ppi' parameter of ata_host_alloc_pinfo() points to an array starting with a NULL pointer, there's going to be a kernel oops as the 'pi' local variable won't get reassigned from the initial value of NULL. Initialize 'pi' instead to '&ata_dummy_port_info' to fix the possible kernel oops for good... Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. | ["https://git.kernel.org/stable/c/07cbdb4807d369fbda73062a91b570c4dc5ec429","https://git.kernel.org/stable/c/1ac5efee33f29e704226506d429b84575a5d66f8","https://git.kernel.org/stable/c/253334f84c81bc6a43af489f108c0bddad989eef","https://git.kernel.org/stable/c/36cd19e7d4e5571d77a2ed20c5b6ef50cf57734a","https://git.kernel.org/stable/c/a810bd5af06977a847d1f202b22d7defd5c62497","https://git.kernel.org/stable/c/bf476fe22aa1851bab4728e0c49025a6a0bea307","https://git.kernel.org/stable/c/ca4693e6e06e4fd2b240c0fec47aa2498c94848e","https://git.kernel.org/stable/c/ff128fbea720bf763fa345680dda5f050bc24a47"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33740 | High | fixed |
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). | ["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50106 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix race between laundromat and free_stateid There is a race between laundromat handling of revoked delegations and a client sending free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revoke_delegation() function for this particular delegation but that means it will no release the lock lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning: kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dump_backtrace+0x98/0x120 kernel: show_stack+0x1c/0x30 kernel: dump_stack_lvl+0x80/0xe8 kernel: print_address_description.constprop.0+0x84/0x390 kernel: print_report+0xa4/0x268 kernel: kasan_report+0xb4/0xf8 kernel: __asan_report_load8_noabort+0x1c/0x28 kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd] kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd] kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd] kernel: nfsd4_open+0xa08/0xe80 [nfsd] kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd] kernel: nfsd_dispatch+0x22c/0x718 [nfsd] kernel: svc_process_common+0x8e8/0x1960 [sunrpc] kernel: svc_process+0x3d4/0x7e0 [sunrpc] kernel: svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 This patch proposes a fixed that's based on adding 2 new additional stid's sc_status values that help coordinate between the laundromat and other operations (nfsd4_free_stateid() and nfsd4_delegreturn()). First to make sure, that once the stid is marked revoked, it is not removed by the nfsd4_free_stateid(), the laundromat take a reference on the stateid. Then, coordinating whether the stid has been put on the cl_revoked list or we are processing FREE_STATEID and need to make sure to remove it from the list, each check that state and act accordingly. If laundromat has added to the cl_revoke list before the arrival of FREE_STATEID, then nfsd4_free_stateid() knows to remove it from the list. If nfsd4_free_stateid() finds that operations arrived before laundromat has placed it on cl_revoke list, it marks the state freed and then laundromat will no longer add it to the list. Also, for nfsd4_delegreturn() when looking for the specified stid, we need to access stid that are marked removed or freeable, it means the laundromat has started processing it but hasn't finished and this delegreturn needs to return nfserr_deleg_revoked and not nfserr_bad_stateid. The latter will not trigger a FREE_STATEID and the lack of it will leave this stid on the cl_revoked list indefinitely. | ["https://git.kernel.org/stable/c/8dd91e8d31febf4d9cca3ae1bb4771d33ae7ee5a","https://git.kernel.org/stable/c/967faa26f313a62e7bebc55d5b8122eaee43b929"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44998 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: atm: idt77252: prevent use after free in dequeue_rx() We can't dereference "skb" after calling vcc->push() because the skb is released. | ["https://git.kernel.org/stable/c/09e086a5f72ea27c758b3f3b419a69000c32adc1","https://git.kernel.org/stable/c/1cece837e387c039225f19028df255df87a97c0d","https://git.kernel.org/stable/c/24cf390a5426aac9255205e9533cdd7b4235d518","https://git.kernel.org/stable/c/379a6a326514a3e2f71b674091dfb0e0e7522b55","https://git.kernel.org/stable/c/628ea82190a678a56d2ec38cda3addf3b3a6248d","https://git.kernel.org/stable/c/91b4850e7165a4b7180ef1e227733bcb41ccdf10","https://git.kernel.org/stable/c/a9a18e8f770c9b0703dab93580d0b02e199a4c79","https://git.kernel.org/stable/c/ef23c18ab88e33ce000d06a5c6aad0620f219bfd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50150 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated--- | ["https://git.kernel.org/stable/c/1ded6b12499e6dee9b0e1ceac633be36538f6fc2","https://git.kernel.org/stable/c/2b0b33e8a58388fa9078f0fbe9af1900e6b08879","https://git.kernel.org/stable/c/2c15c4133d00f5da632fce60ed013fc31aa9aa58","https://git.kernel.org/stable/c/68a7c7fe322546be1464174c8d85874b8161deda","https://git.kernel.org/stable/c/6af43ec3bf40f8b428d9134ffa7a291aecd60da8","https://git.kernel.org/stable/c/87474406056891e4fdea0794e1f632b21b3dfa27","https://git.kernel.org/stable/c/bee1b68cb8bcee4fd3a8bde3a4886e0b1375dc4d","https://git.kernel.org/stable/c/befab3a278c59db0cc88c8799638064f6d3fd6f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50209 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances. | ["https://git.kernel.org/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c","https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f746b2c07","https://git.kernel.org/stable/c/ba9045887b435a4c5551245ae034b8791b4e4aaa","https://git.kernel.org/stable/c/c5c1ae73b7741fa3b58e6e001b407825bb971225","https://git.kernel.org/stable/c/c71957271f2e8133a6aa82001c2fa671d5008129","https://git.kernel.org/stable/c/dbe51dd516e6d4e655f31c8a1cbc050dde7ba97b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-31436 | High | fixed |
|
qfq_change_class in net/sched/sch_qfq.c in the Linux kernel before 6.2.13 allows an out-of-bounds write because lmax can exceed QFQ_MIN_LMAX. | ["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13","https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://security.netapp.com/advisory/ntap-20230609-0001/","https://www.debian.org/security/2023/dsa-5402","https://www.spinics.net/lists/stable-commits/msg294885.html","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.13","https://github.com/torvalds/linux/commit/3037933448f60f9acb705997eae62013ecb81e0d","https://lists.debian.org/debian-lts-announce/2023/06/msg00008.html","https://security.netapp.com/advisory/ntap-20230609-0001/","https://www.debian.org/security/2023/dsa-5402","https://www.spinics.net/lists/stable-commits/msg294885.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53059 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer. | ["https://git.kernel.org/stable/c/07a6e3b78a65f4b2796a8d0d4adb1a15a81edead","https://git.kernel.org/stable/c/3eb986c64c6bfb721950f9666a3b723cf65d043f","https://git.kernel.org/stable/c/3f45d590ccbae6dfd6faef54efe74c30bd85d3da","https://git.kernel.org/stable/c/45a628911d3c68e024eed337054a0452b064f450","https://git.kernel.org/stable/c/64d63557ded6ff3ce72b18ab87a6c4b1b652161c","https://git.kernel.org/stable/c/9480c3045f302f43f9910d2d556d6cf5a62c1822","https://git.kernel.org/stable/c/9c98ee7ea463a838235e7a0e35851b38476364f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3776 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation. If tcf_change_indev() fails, fw_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability. We recommend upgrading past commit 0323bce598eea038714f941ce2b22541c46d488f. | ["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f","https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20240202-0003/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=0323bce598eea038714f941ce2b22541c46d488f","https://kernel.dance/0323bce598eea038714f941ce2b22541c46d488f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20240202-0003/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38662 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Allow delete from sockmap/sockhash only if update is allowed We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash. We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map. From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types. | ["https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1","https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9","https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d","https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e","https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d","https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c","https://git.kernel.org/stable/c/000a65bf1dc04fb2b65e2abf116f0bc0fc2ee7b1","https://git.kernel.org/stable/c/11e8ecc5b86037fec43d07b1c162e233e131b1d9","https://git.kernel.org/stable/c/29467edc23818dc5a33042ffb4920b49b090e63d","https://git.kernel.org/stable/c/6693b172f008846811f48a099f33effc26068e1e","https://git.kernel.org/stable/c/98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d","https://git.kernel.org/stable/c/b81e1c5a3c70398cf76631ede63a03616ed1ba3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47432 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Don't overflow in peek() When we started spreading new inode numbers throughout most of the 64 bit inode space, that triggered some corner case bugs, in particular some integer overflows related to the radix tree code. Oops. | ["https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac","https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0","https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437","https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c","https://git.kernel.org/stable/c/784d01f9bbc282abb0c5ade5beb98a87f50343ac","https://git.kernel.org/stable/c/9492261ff2460252cf2d8de89cdf854c7e2b28a0","https://git.kernel.org/stable/c/aa7f1827953100cdde0795289a80c6c077bfe437","https://git.kernel.org/stable/c/ec298b958cb0c40d70c68079da933c8f31c5134c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48692 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Set scmnd->result only when scmnd is not NULL This change fixes the following kernel NULL pointer dereference which is reproduced by blktests srp/007 occasionally. BUG: kernel NULL pointer dereference, address: 0000000000000170 PGD 0 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1H Kdump: loaded Not tainted 6.0.0-rc1+ #37 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.15.0-29-g6a62e0cb0dfe-prebuilt.qemu.org 04/01/2014 Workqueue: 0x0 (kblockd) RIP: 0010:srp_recv_done+0x176/0x500 [ib_srp] Code: 00 4d 85 ff 0f 84 52 02 00 00 48 c7 82 80 02 00 00 00 00 00 00 4c 89 df 4c 89 14 24 e8 53 d3 4a f6 4c 8b 14 24 41 0f b6 42 13 <41> 89 87 70 01 00 00 41 0f b6 52 12 f6 c2 02 74 44 41 8b 42 1c b9 RSP: 0018:ffffaef7c0003e28 EFLAGS: 00000282 RAX: 0000000000000000 RBX: ffff9bc9486dea60 RCX: 0000000000000000 RDX: 0000000000000102 RSI: ffffffffb76bbd0e RDI: 00000000ffffffff RBP: ffff9bc980099a00 R08: 0000000000000001 R09: 0000000000000001 R10: ffff9bca53ef0000 R11: ffff9bc980099a10 R12: ffff9bc956e14000 R13: ffff9bc9836b9cb0 R14: ffff9bc9557b4480 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9bc97ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000170 CR3: 0000000007e04000 CR4: 00000000000006f0 Call Trace: <IRQ> __ib_process_cq+0xb7/0x280 [ib_core] ib_poll_handler+0x2b/0x130 [ib_core] irq_poll_softirq+0x93/0x150 __do_softirq+0xee/0x4b8 irq_exit_rcu+0xf7/0x130 sysvec_apic_timer_interrupt+0x8e/0xc0 </IRQ> | ["https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa","https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb","https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624","https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413","https://git.kernel.org/stable/c/12f35199a2c0551187edbf8eb01379f0598659fa","https://git.kernel.org/stable/c/a8edd49c94b4b08019ed7d6dd794fca8078a4deb","https://git.kernel.org/stable/c/f022576aa03c2385ea7f2b27ee5b331e43abf624","https://git.kernel.org/stable/c/f2c70f56f762e5dc3b0d7dc438fbb137cb116413"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52653 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation. | ["https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4","https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c","https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822","https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa","https://git.kernel.org/stable/c/47ac11db93e74ac49cd6c3fc69bcbc5964c4a8b4","https://git.kernel.org/stable/c/99044c01ed5329e73651c054d8a4baacdbb1a27c","https://git.kernel.org/stable/c/d111e30d9cd846bb368faf3637dc0f71fcbcf822","https://git.kernel.org/stable/c/e67b652d8e8591d3b1e569dbcdfcee15993e91fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27041 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini() Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there. Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. | ["https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b","https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c","https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957","https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811","https://git.kernel.org/stable/c/1c62697e4086de988b31124fb8c79c244ea05f2b","https://git.kernel.org/stable/c/2a3cfb9a24a28da9cc13d2c525a76548865e182c","https://git.kernel.org/stable/c/ca2eb375db76fd50f31afdd67d6ca4f833254957","https://git.kernel.org/stable/c/e040f1fbe9abae91b12b074cfc3bbb5367b79811"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35865 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in smb2_is_valid_oplock_break() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd","https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4","https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628","https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7","https://git.kernel.org/stable/c/21fed37d2bdcde33453faf61d3d4d96c355f04bd","https://git.kernel.org/stable/c/22863485a4626ec6ecf297f4cc0aef709bc862e4","https://git.kernel.org/stable/c/3dba0e5276f131e36d6d8043191d856f49238628","https://git.kernel.org/stable/c/84488466b7a69570bdbf76dd9576847ab97d54e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36479 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fpga: bridge: add owner module and take its refcount The current implementation of the fpga bridge assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the bridge if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_bridge struct and use it to take the module's refcount. Modify the function for registering a bridge to take an additional owner module parameter and rename it to avoid conflicts. Use the old function name for a helper macro that automatically sets the module that registers the bridge as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a bridge without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga bridge. Other changes: opportunistically move put_device() from __fpga_bridge_get() to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since the bridge device is taken in these functions. | ["https://git.kernel.org/stable/c/18dc8366abb6cadcb77668b1a16434654e355d49","https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529","https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125","https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b","https://git.kernel.org/stable/c/1da11f822042eb6ef4b6064dc048f157a7852529","https://git.kernel.org/stable/c/6896b6b2e2d9ec4e1b0acb4c1698a75a4b34d125","https://git.kernel.org/stable/c/d7c4081c54a1d4068de9440957303a76f9e5c95b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-37021 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fpga: manager: add owner module and take its refcount The current implementation of the fpga manager assumes that the low-level module registers a driver for the parent device and uses its owner pointer to take the module's refcount. This approach is problematic since it can lead to a null pointer dereference while attempting to get the manager if the parent device does not have a driver. To address this problem, add a module owner pointer to the fpga_manager struct and use it to take the module's refcount. Modify the functions for registering the manager to take an additional owner module parameter and rename them to avoid conflicts. Use the old function names for helper macros that automatically set the module that registers the manager as the owner. This ensures compatibility with existing low-level control modules and reduces the chances of registering a manager without setting the owner. Also, update the documentation to keep it consistent with the new interface for registering an fpga manager. Other changes: opportunistically move put_device() from __fpga_mgr_get() to fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the manager device is taken in these functions. | ["https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad","https://git.kernel.org/stable/c/304f8032d601d4f9322ca841cd0b573bd1beb158","https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9","https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb","https://git.kernel.org/stable/c/2da62a139a6221a345db4eb9f4f1c4b0937c89ad","https://git.kernel.org/stable/c/4d4d2d4346857bf778fafaa97d6f76bb1663e3c9","https://git.kernel.org/stable/c/62ac496a01c9337a11362cea427038ba621ca9eb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46715 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: driver: iio: add missing checks on iio_info's callback access Some callbacks from iio_info structure are accessed without any check, so if a driver doesn't implement them trying to access the corresponding sysfs entries produce a kernel oops such as: [ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute [...] [ 2203.783416] Call trace: [ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48 [ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120 [ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4 [ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0 [ 2203.802236] vfs_read from ksys_read+0xa4/0xd4 [ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54 [ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0) [ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000 [ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000 [ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0 [ 2203.830363] Code: bad PC value [ 2203.832695] ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/0cc7e0ee31e5c44904e98e2229d591e093282a70","https://git.kernel.org/stable/c/72f022ebb9deac28663fa4c04ba315ed5d6654d1","https://git.kernel.org/stable/c/c4ec8dedca961db056ec85cb7ca8c9f7e2e92252","https://git.kernel.org/stable/c/dc537a72f64890d883d24ae4ac58733fc5bc523d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48693 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugs In brcmstb_pm_probe(), there are two kinds of leak bugs: (1) we need to add of_node_put() when for_each__matching_node() breaks (2) we need to add iounmap() for each iomap in fail path | ["https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883","https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1","https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d","https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b","https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82","https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558","https://git.kernel.org/stable/c/0284b4e6dec6088a41607aa3f42bf51edff01883","https://git.kernel.org/stable/c/1085f5080647f0c9f357c270a537869191f7f2a1","https://git.kernel.org/stable/c/43245c77d9efd8c9eb91bf225d07954dcf32204d","https://git.kernel.org/stable/c/57b2897ec3ffe4cbe018446be6d04432919dca6b","https://git.kernel.org/stable/c/653500b400d5576940b7429690f7197199ddcc82","https://git.kernel.org/stable/c/6dc0251638a4a1a998506dbd4627f8317e907558"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48708 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference Added checking of pointer "function" in pcs_set_mux(). pinmux_generic_get_function() can return NULL and the pointer "function" was dereferenced without checking against NULL. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db","https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb","https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208","https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26","https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2","https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b","https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33","https://git.kernel.org/stable/c/1177bdafe87cbe543a2dc48a9bbac265aa5864db","https://git.kernel.org/stable/c/2b763f7de108cb1a5ad5ed08e617d677341947cb","https://git.kernel.org/stable/c/6e2a0521e4e84a2698f2da3950fb5c5496a4d208","https://git.kernel.org/stable/c/71668706fbe7d20e6f172fa3287fa8aac1b56c26","https://git.kernel.org/stable/c/bcc487001a15f71f103d102cba4ac8145d7a68f2","https://git.kernel.org/stable/c/d2d73e6d4822140445ad4a7b1c6091e0f5fe703b","https://git.kernel.org/stable/c/e671e63587c92b3fd767cf82e73129f6d5feeb33"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48836 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: aiptek - properly check endpoint type Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint. Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints Fail log: usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace: <TASK> aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830 input_open_device+0x1bb/0x320 drivers/input/input.c:629 kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593 | ["https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7","https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8","https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821","https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f","https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c","https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31","https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a","https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6","https://git.kernel.org/stable/c/35069e654bcab567ff8b9f0e68e1caf82c15dcd7","https://git.kernel.org/stable/c/5600f6986628dde8881734090588474f54a540a8","https://git.kernel.org/stable/c/57277a8b5d881e02051ba9d7f6cb3f915c229821","https://git.kernel.org/stable/c/6de20111cd0bb7da9b2294073ba00c7d2a6c1c4f","https://git.kernel.org/stable/c/e732b0412f8c603d1e998f3bff41b5e7d5c3914c","https://git.kernel.org/stable/c/e762f57ff255af28236cd02ca9fc5c7e5a089d31","https://git.kernel.org/stable/c/f0d43d22d24182b94d7eb78a2bf6ae7e2b33204a","https://git.kernel.org/stable/c/fc8033a55e2796d21e370260a784ac9fbb8305a6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48838 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: Fix use-after-free bug by not setting udc->dev.driver The syzbot fuzzer found a use-after-free bug: BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689 CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094 Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does: if (dev->driver) add_uevent_var(env, "DRIVER=%s", dev->driver->name); and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL. The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL. In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC. This patch simply removes the statements in the gadget core that touch udc->dev.driver. | ["https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646","https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740","https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a","https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5","https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e","https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b","https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e","https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3","https://git.kernel.org/stable/c/00bdd9bf1ac6d401ad926d3d8df41b9f1399f646","https://git.kernel.org/stable/c/16b1941eac2bd499f065a6739a40ce0011a3d740","https://git.kernel.org/stable/c/2015c23610cd0efadaeca4d3a8d1dae9a45aa35a","https://git.kernel.org/stable/c/2282a6eb6d4e118e294e43dcc421e0e0fe4040b5","https://git.kernel.org/stable/c/27d64436984fb8835a8b7e95993193cc478b162e","https://git.kernel.org/stable/c/4325124dde6726267813c736fee61226f1d38f0b","https://git.kernel.org/stable/c/609a7119bffe3ddd7c93f2fa65be8917e02a0b7e","https://git.kernel.org/stable/c/e2d3a7009e505e120805f449c832942660f3f7f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52662 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init. | ["https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf","https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a","https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6","https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5","https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce","https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876","https://git.kernel.org/stable/c/03b1072616a8f7d6e8594f643b416a9467c83fbf","https://git.kernel.org/stable/c/40624af6674745e174c754a20d7c53c250e65e7a","https://git.kernel.org/stable/c/6fc6233f6db1579b69b54b44571f1a7fde8186e6","https://git.kernel.org/stable/c/83e0f220d1e992fa074157fcf14945bf170ffbc5","https://git.kernel.org/stable/c/89709105a6091948ffb6ec2427954cbfe45358ce","https://git.kernel.org/stable/c/d1e546ab91c670e536a274a75481034ab7534876"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52826 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference In tpg110_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea","https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c","https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc","https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca","https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f","https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658","https://git.kernel.org/stable/c/84c923d898905187ebfd4c0ef38cd1450af7e0ea","https://git.kernel.org/stable/c/9268bfd76bebc85ff221691b61498cc16d75451c","https://git.kernel.org/stable/c/9acc2bc00135e9ecd13a70ce1140e2673e504cdc","https://git.kernel.org/stable/c/d0bc9ab0a161a9745273f5bf723733a8e6c57aca","https://git.kernel.org/stable/c/eaede6900c0961b072669d6bd97fe8f90ed1900f","https://git.kernel.org/stable/c/f22def5970c423ea7f87d5247bd0ef91416b0658"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52833 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: Add date->evt_skb is NULL check fix crash because of null pointers [ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 6104.969667] #PF: supervisor read access in kernel mode [ 6104.969668] #PF: error_code(0x0000) - not-present page [ 6104.969670] PGD 0 P4D 0 [ 6104.969673] Oops: 0000 [#1] SMP NOPTI [ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb] [ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246 [ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006 [ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000 [ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001 [ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0 [ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90 [ 6104.969697] FS: 00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000 [ 6104.969699] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0 [ 6104.969701] PKRU: 55555554 [ 6104.969702] Call Trace: [ 6104.969708] btusb_mtk_shutdown+0x44/0x80 [btusb] [ 6104.969732] hci_dev_do_close+0x470/0x5c0 [bluetooth] [ 6104.969748] hci_rfkill_set_block+0x56/0xa0 [bluetooth] [ 6104.969753] rfkill_set_block+0x92/0x160 [ 6104.969755] rfkill_fop_write+0x136/0x1e0 [ 6104.969759] __vfs_write+0x18/0x40 [ 6104.969761] vfs_write+0xdf/0x1c0 [ 6104.969763] ksys_write+0xb1/0xe0 [ 6104.969765] __x64_sys_write+0x1a/0x20 [ 6104.969769] do_syscall_64+0x51/0x180 [ 6104.969771] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 6104.969773] RIP: 0033:0x7f5a21f18fef [ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 [ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef [ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012 [ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017 [ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002 [ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0 | ["https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30","https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a","https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9","https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3","https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0","https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c","https://git.kernel.org/stable/c/0048ddf045bddc4dacb3e783fd869a2f8fb5be30","https://git.kernel.org/stable/c/13b1ebad4c175e6a9b0748acbf133c21a15d282a","https://git.kernel.org/stable/c/624820f7c8826dd010e8b1963303c145f99816e9","https://git.kernel.org/stable/c/9f8e4d1a4ca1179aaeb43f91f3e2a386e7e616b3","https://git.kernel.org/stable/c/a556f2ef556a04790f67f2fa272f1a77336d15a0","https://git.kernel.org/stable/c/f9de14bde56dcbb0765284c6dfc35842b021733c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52841 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: mux: Add check and kfree for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak. | ["https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78","https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb","https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68","https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4","https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785","https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d","https://git.kernel.org/stable/c/1fd6eb12642e0c32692924ff359c07de4b781d78","https://git.kernel.org/stable/c/64863ba8e6b7651d994c6e6d506cc8aa2ac45edb","https://git.kernel.org/stable/c/980be4c3b0d51c0f873fd750117774561c66cf68","https://git.kernel.org/stable/c/a254ee1ddc592ae1efcce96b8c014e1bd2d5a2b4","https://git.kernel.org/stable/c/aae7598aff291d4d140be1355aa20930af948785","https://git.kernel.org/stable/c/cb13001411999adb158b39e76d94705eb2da100d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwmon: (axi-fan-control) Fix possible NULL pointer dereference axi_fan_control_irq_handler(), dependent on the private axi_fan_control_data structure, might be called before the hwmon device is registered. That will cause an "Unable to handle kernel NULL pointer dereference" error. | ["https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0","https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105","https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a","https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062","https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb","https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0","https://git.kernel.org/stable/c/2a5b3370a1d9750eca325292e291c8c7cb8cf2e0","https://git.kernel.org/stable/c/33de53a2706066d526173dc743faf43d92c62105","https://git.kernel.org/stable/c/7d870088db4863c514a7f8751cd593751983029a","https://git.kernel.org/stable/c/b3e7eb23a6e97642ff3190431c06475d9ca1e062","https://git.kernel.org/stable/c/c49f14cc1bb12c625a1c572e8a95b6adefd4d8eb","https://git.kernel.org/stable/c/f62b8969847850ba7596cb145cc47c65ea57dae0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52873 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0","https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a","https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e","https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b","https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e","https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b","https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae","https://git.kernel.org/stable/c/1f57f78fbacf630430bf954e5a84caafdfea30c0","https://git.kernel.org/stable/c/3994387ba3564976731179c4d4a6d7850ddda71a","https://git.kernel.org/stable/c/a90239551abc181687f8c0ba60b276f7d75c141e","https://git.kernel.org/stable/c/ca6d565a2319d69d9766e6ecbb5af827fc4afb2b","https://git.kernel.org/stable/c/df1c4a9efa3f5b6fb5e0ae63890230dbe2190b7e","https://git.kernel.org/stable/c/f6a7c51cf07a399ec067d39f0a22f1817c5c7d2b","https://git.kernel.org/stable/c/fbe466f06d4ea18745da0d57540539b7b36936ae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52876 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9","https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7","https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22","https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783","https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592","https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b","https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68","https://git.kernel.org/stable/c/0884393c63cc9a1772f7121a6645ba7bd76feeb9","https://git.kernel.org/stable/c/1639072f6260babd017556e9f236ca2ad589d1e7","https://git.kernel.org/stable/c/96e9544a0c4faca616b3f9f4034dcd83a14e7f22","https://git.kernel.org/stable/c/a540ca0aeae83c2f3964bcb4e383f64ce2ec1783","https://git.kernel.org/stable/c/b20cfe007a46f8c165d42a05c50a8d3d893e6592","https://git.kernel.org/stable/c/c4070ada5d5155c8d4d17ea64bd246949889f25b","https://git.kernel.org/stable/c/cfa68e0ac5dcde43577adadf6f0f26f3b365ad68"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26950 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wireguard: netlink: access device through ctx instead of peer The previous commit fixed a bug that led to a NULL peer->device being dereferenced. It's actually easier and faster performance-wise to instead get the device from ctx->wg. This semantically makes more sense too, since ctx->wg->peer_allowedips.seq is compared with ctx->allowedips_seq, basing them both in ctx. This also acts as a defence in depth provision against freed peers. | ["https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5","https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068","https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5","https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f","https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996","https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37","https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47","https://git.kernel.org/stable/c/09c3fa70f65175861ca948cb2f0f791e666c90e5","https://git.kernel.org/stable/c/493aa6bdcffd90a4f82aa614fe4f4db0641b4068","https://git.kernel.org/stable/c/4be453271a882c8ebc28df3dbf9e4d95e6ac42f5","https://git.kernel.org/stable/c/71cbd32e3db82ea4a74e3ef9aeeaa6971969c86f","https://git.kernel.org/stable/c/93bcc1752c69bb309f4d8cfaf960ef1faeb34996","https://git.kernel.org/stable/c/c991567e6c638079304cc15dff28748e4a3c4a37","https://git.kernel.org/stable/c/d44bd323d8bb8031eef4bdc44547925998a11e47","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26964 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Add error handling in xhci_map_urb_for_dma Currently xhci_map_urb_for_dma() creates a temporary buffer and copies the SG list to the new linear buffer. But if the kzalloc_node() fails, then the following sg_pcopy_to_buffer() can lead to crash since it tries to memcpy to NULL pointer. So return -ENOMEM if kzalloc returns null pointer. | ["https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd","https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4","https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757","https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d","https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea","https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052","https://git.kernel.org/stable/c/4a49d24fdec0a802aa686a567a3989a9fdf4e5dd","https://git.kernel.org/stable/c/620b6cf2f1a270f48d38e6b8ce199c1acb3e90f4","https://git.kernel.org/stable/c/7b6cc33593d7ccfc3011b290849cfa899db46757","https://git.kernel.org/stable/c/962300a360d24c5be5a188cda48da58a37e4304d","https://git.kernel.org/stable/c/b2c898469dfc388f619c6c972a28466cbb1442ea","https://git.kernel.org/stable/c/be95cc6d71dfd0cba66e3621c65413321b398052"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | ["https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52","https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb","https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6","https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b","https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d","https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d","https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198","https://git.kernel.org/stable/c/421b135aceace99789c982f6a77ce9476564fb52","https://git.kernel.org/stable/c/852db52b45ea96dac2720f108e7c7331cd3738bb","https://git.kernel.org/stable/c/ae60e3342296f766f88911d39199f77b05f657a6","https://git.kernel.org/stable/c/b4527ee3de365a742215773d20f07db3e2c06f3b","https://git.kernel.org/stable/c/cdbc6e2d8108bc47895e5a901cfcaf799b00ca8d","https://git.kernel.org/stable/c/db4066e3ab6b3d918ae2b92734a89c04fe82cc1d","https://git.kernel.org/stable/c/dcb13b5c9ae8743f99a96f392186527c3df89198","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27037 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: zynq: Prevent null pointer dereference caused by kmalloc failure The kmalloc() in zynq_clk_setup() will return null if the physical memory has run out. As a result, if we use snprintf() to write data to the null address, the null pointer dereference bug will happen. This patch uses a stack variable to replace the kmalloc(). | ["https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db","https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85","https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b","https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6","https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d","https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8","https://git.kernel.org/stable/c/01511ac7be8e45f80e637f6bf61af2d3d2dee9db","https://git.kernel.org/stable/c/0801c893fd48cdba66a3c8f44c3fe43cc67d3b85","https://git.kernel.org/stable/c/58a946ab43501f2eba058d24d96af0ad1122475b","https://git.kernel.org/stable/c/7938e9ce39d6779d2f85d822cc930f73420e54a6","https://git.kernel.org/stable/c/8c4889a9ea861d7be37463c10846eb75e1b49c9d","https://git.kernel.org/stable/c/ca976c6a592f789700200069ef9052493c0b73d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27047 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: fix phy_get_internal_delay accessing an empty array The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0. | ["https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad","https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b","https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a","https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8","https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79","https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563","https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b","https://git.kernel.org/stable/c/0307cf443308ecc6be9b2ca312bb31bae5e5a7ad","https://git.kernel.org/stable/c/06dd21045a7e8bc8701b0ebedcd9a30a6325878b","https://git.kernel.org/stable/c/0e939a002c8a7d66e60bd0ea6b281fb39d713c1a","https://git.kernel.org/stable/c/2a2ff709511617de9c6c072eeee82bcbbdfecaf8","https://git.kernel.org/stable/c/4469c0c5b14a0919f5965c7ceac96b523eb57b79","https://git.kernel.org/stable/c/589ec16174dd9378953b8232ae76fad0a96e1563","https://git.kernel.org/stable/c/c0691de7df1d51482a52cac93b7fe82fd9dd296b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27051 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5","https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db","https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035","https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567","https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6","https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095","https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6","https://git.kernel.org/stable/c/74b84d0d71180330efe67c82f973a87f828323e5","https://git.kernel.org/stable/c/9127599c075caff234359950117018a010dd01db","https://git.kernel.org/stable/c/b25b64a241d769e932a022e5c780cf135ef56035","https://git.kernel.org/stable/c/d951cf510fb0df91d3abac0121a59ebbc63c0567","https://git.kernel.org/stable/c/e6e3e51ffba0784782b1a076d7441605697ea3c6","https://git.kernel.org/stable/c/e72160cb6e23b78b41999d6885a34ce8db536095","https://git.kernel.org/stable/c/f661017e6d326ee187db24194cabb013d81bc2a6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27054 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount decrement Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same. | ["https://git.kernel.org/stable/c/9fe0562179d8fa960afca0eaed6d4ba4122a3cc6","https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a","https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06","https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5","https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e","https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19","https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650","https://git.kernel.org/stable/c/ad999aa18103fa038787b6a8a55020abcf34df1a","https://git.kernel.org/stable/c/c3116e62ddeff79cae342147753ce596f01fcf06","https://git.kernel.org/stable/c/ebc5a3bd79e54f98c885c26f0862a27a02c487c5","https://git.kernel.org/stable/c/ec09bcab32fc4765e0cc97e1b72cdd067135f37e","https://git.kernel.org/stable/c/edbdb0d94143db46edd373cc93e433832d29fe19","https://git.kernel.org/stable/c/fa18aa507ea71d8914b6acb2c94db311c757c650"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27393 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Add missing skb_mark_for_recycle Notice that skb_mark_for_recycle() is introduced later than fixes tag in commit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling"). It is believed that fixes tag were missing a call to page_pool_release_page() between v5.9 to v5.14, after which is should have used skb_mark_for_recycle(). Since v6.6 the call page_pool_release_page() were removed (in commit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()") and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch 'net-page_pool-remove-page_pool_release_page'")). This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catch page_pool memory leaks"). | ["https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f","https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629","https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1","https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6","https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4","http://www.openwall.com/lists/oss-security/2024/05/08/4","http://xenbits.xen.org/xsa/advisory-457.html","https://git.kernel.org/stable/c/037965402a010898d34f4e35327d22c0a95cd51f","https://git.kernel.org/stable/c/27aa3e4b3088426b7e34584274ad45b5afaf7629","https://git.kernel.org/stable/c/4143b9479caa29bb2380f3620dcbe16ea84eb3b1","https://git.kernel.org/stable/c/7c1250796b6c262b505a46192f4716b8c6a6a8c6","https://git.kernel.org/stable/c/c8b7b2f158d9d4fb89cd2f68244af154f7549bb4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35829 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/lima: fix a memleak in lima_heap_alloc When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. | ["https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea","https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab","https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f","https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7","https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd","https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed","https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf","https://git.kernel.org/stable/c/04ae3eb470e52a3c41babe85ff8cee195e4dcbea","https://git.kernel.org/stable/c/4ab14eccf5578af1dd5668a5f2d771df27683cab","https://git.kernel.org/stable/c/746606d37d662c70ae1379fc658ee9c65f06880f","https://git.kernel.org/stable/c/8e25c0ee5665e8a768b8e21445db1f86e9156eb7","https://git.kernel.org/stable/c/ec6bb037e4a35fcbb5cd7bc78242d034ed893fcd","https://git.kernel.org/stable/c/f2e80ac9344aebbff576453d5c0290b332e187ed","https://git.kernel.org/stable/c/f6d51a91b41704704e395de6839c667b0f810bbf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35833 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMA This dma_alloc_coherent() is undone neither in the remove function, nor in the error handling path of fsl_qdma_probe(). Switch to the managed version to fix both issues. | ["https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3","https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24","https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8","https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59","https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714","https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6","https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802","https://git.kernel.org/stable/c/15eb996d7d13cb72a16389231945ada8f0fef2c3","https://git.kernel.org/stable/c/198270de9d8eb3b5d5f030825ea303ef95285d24","https://git.kernel.org/stable/c/1c75fe450b5200c78f4a102a0eb8e15d8f1ccda8","https://git.kernel.org/stable/c/25ab4d72eb7cbfa0f3d97a139a9b2bfcaa72dd59","https://git.kernel.org/stable/c/3aa58cb51318e329d203857f7a191678e60bb714","https://git.kernel.org/stable/c/5cd8a51517ce15edbdcea4fc74c4c127ddaa1bd6","https://git.kernel.org/stable/c/ae6769ba51417c1c86fb645812d5bff455eee802","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36008 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: check for NULL idev in ip_route_use_hint() syzbot was able to trigger a NULL deref in fib_validate_source() in an old tree [1]. It appears the bug exists in latest trees. All calls to __in_dev_get_rcu() must be checked for a NULL result. [1] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425 Code: 18 f2 f2 f2 f2 42 c7 44 20 23 f3 f3 f3 f3 48 89 44 24 78 42 c6 44 20 27 f3 e8 5d 88 48 fc 4c 89 e8 48 c1 e8 03 48 89 44 24 18 <42> 80 3c 20 00 74 08 4c 89 ef e8 d2 15 98 fc 48 89 5c 24 10 41 bf RSP: 0018:ffffc900015fee40 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0 RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0 RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000 R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000 FS: 00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231 ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327 ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline] ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638 ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673 __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline] __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620 __netif_receive_skb_list net/core/dev.c:5672 [inline] netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764 netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816 xdp_recv_frames net/bpf/test_run.c:257 [inline] xdp_test_run_batch net/bpf/test_run.c:335 [inline] bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363 bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376 bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736 __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115 __do_sys_bpf kernel/bpf/syscall.c:5201 [inline] __se_sys_bpf kernel/bpf/syscall.c:5199 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199 | ["https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1","https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1","https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0","https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4","https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655","https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295","https://git.kernel.org/stable/c/03b5a9b2b526862b21bcc31976e393a6e63785d1","https://git.kernel.org/stable/c/58a4c9b1e5a3e53c9148e80b90e1e43897ce77d1","https://git.kernel.org/stable/c/7a25bfd12733a8f38f8ca47c581f876c3d481ac0","https://git.kernel.org/stable/c/7da0f91681c4902bc5c210356fdd963b04d5d1d4","https://git.kernel.org/stable/c/8240c7308c941db4d9a0a91b54eca843c616a655","https://git.kernel.org/stable/c/c71ea3534ec0936fc57e6fb271c7cc6a2f68c295","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36965 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: remoteproc: mediatek: Make sure IPI buffer fits in L2TCM The IPI buffer location is read from the firmware that we load to the System Companion Processor, and it's not granted that both the SRAM (L2TCM) size that is defined in the devicetree node is large enough for that, and while this is especially true for multi-core SCP, it's still useful to check on single-core variants as well. Failing to perform this check may make this driver perform R/W operations out of the L2TCM boundary, resulting (at best) in a kernel panic. To fix that, check that the IPI buffer fits, otherwise return a failure and refuse to boot the relevant SCP core (or the SCP at all, if this is single core). | ["https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf","https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2","https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e","https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42","https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9","https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf","https://git.kernel.org/stable/c/00548ac6b14428719c970ef90adae2b3b48c0cdf","https://git.kernel.org/stable/c/1d9e2de24533daca36cbf09e8d8596bf72b526b2","https://git.kernel.org/stable/c/26c6d7dc8c6a9fde9d362ab2eef6390efeff145e","https://git.kernel.org/stable/c/331f91d86f71d0bb89a44217cc0b2a22810bbd42","https://git.kernel.org/stable/c/36c79eb4845551e9f6d28c663b38ce0ab03b84a9","https://git.kernel.org/stable/c/838b49e211d59fa827ff9df062d4020917cffbdf"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36967 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak in tpm2_key_encode() 'scratch' is never freed. Fix this by calling kfree() in the success, and in the error case. | ["https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28","https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf","https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7","https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56","https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13","https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248","https://git.kernel.org/stable/c/189c768932d435045b1fae12bf63e53866f06a28","https://git.kernel.org/stable/c/1e6914fa8e7798bcf3ce4a5b96ea4ac1d5571cdf","https://git.kernel.org/stable/c/5d91238b590bd883c86ba7707c5c9096469c08b7","https://git.kernel.org/stable/c/cf26a92f560eed5d6ddc3d441cc645950cbabc56","https://git.kernel.org/stable/c/e62835264d0352be6086975f18fdfed2b5520b13","https://git.kernel.org/stable/c/ffcaa2172cc1a85ddb8b783de96d38ca8855e248"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38571 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/tsens: Fix null pointer dereference compute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c) as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to null pointer dereference (if DEBUG or DYNAMIC_DEBUG set). Fix this bug by adding null pointer check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653","https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f","https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad","https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278","https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f","https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b","https://git.kernel.org/stable/c/06d17744b77bc6cb29a6c785f4fad8c4163ee653","https://git.kernel.org/stable/c/11c731386ed82053c2759b6fea1a82ae946e5e0f","https://git.kernel.org/stable/c/27600e0c5272a262b0903e35ae1df37d33c5c1ad","https://git.kernel.org/stable/c/2d5ca6e4a2872e92a32fdfd87e04dd7d3ced7278","https://git.kernel.org/stable/c/d998ddc86a27c92140b9f7984ff41e3d1d07a48f","https://git.kernel.org/stable/c/fcf5f1b5f308f2eb422f6aca55d295b25890906b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41097 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: atm: cxacru: fix endpoint checking in cxacru_bind() Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usb_submit_urb(). Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type. Unfortunately, this patch has not been tested on real hardware. [1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293 | ["https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a","https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47","https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51","https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a","https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727","https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506","https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781","https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4","https://git.kernel.org/stable/c/1aac4be1aaa5177506219f01dce5e29194e5e95a","https://git.kernel.org/stable/c/23926d316d2836315cb113569f91393266eb5b47","https://git.kernel.org/stable/c/2eabb655a968b862bc0c31629a09f0fbf3c80d51","https://git.kernel.org/stable/c/5159a81924311c1ec786ad9fdef784ead8676a6a","https://git.kernel.org/stable/c/5584c776a1af7807ca815ee6265f2c1429fc5727","https://git.kernel.org/stable/c/75ddbf776dd04a09fb9e5267ead5d0c989f84506","https://git.kernel.org/stable/c/ac9007520e392541a29daebaae8b9109007bc781","https://git.kernel.org/stable/c/f536f09eb45e4de8d1b9accee9d992aa1846f1d4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42089 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl-asoc-card: set priv->pdev before using it priv->pdev pointer was set after being used in fsl_asoc_card_audmux_init(). Move this assignment at the start of the probe function, so sub-functions can correctly use pdev through priv. fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to the dev struct, used with dev_err macros. As priv is zero-initialised, there would be a NULL pointer dereference. Note that if priv->dev is dereferenced before assignment but never used, for example if there is no error to be printed, the driver won't crash probably due to compiler optimisations. | ["https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed","https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9","https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a","https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6","https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a","https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac","https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245","https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a","https://git.kernel.org/stable/c/29bc9e7c75398b0d12fc30955f2e9b2dd29ffaed","https://git.kernel.org/stable/c/3662eb2170e59b58ad479982dc1084889ba757b9","https://git.kernel.org/stable/c/544ab46b7ece6d6bebbdee5d5659c0a0f804a99a","https://git.kernel.org/stable/c/7c18b4d89ff9c810b6e562408afda5ce165c4ea6","https://git.kernel.org/stable/c/8896e18b7c366f8faf9344abfd0971435f1c723a","https://git.kernel.org/stable/c/8faf91e58425c2f6ce773250dfd995f1c2d461ac","https://git.kernel.org/stable/c/90f3feb24172185f1832636264943e8b5e289245","https://git.kernel.org/stable/c/ae81535ce2503aabc4adab3472f4338070cdeb6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52674 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put() Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside scarlett2_mixer_values[]. | ["https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572","https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7","https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2","https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810","https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b","https://git.kernel.org/stable/c/03035872e17897ba89866940bbc9cefca601e572","https://git.kernel.org/stable/c/04f8f053252b86c7583895c962d66747ecdc61b7","https://git.kernel.org/stable/c/ad945ea8d47dd4454c271510bea24850119847c2","https://git.kernel.org/stable/c/d8d8897d65061cbe36bf2909057338303a904810","https://git.kernel.org/stable/c/e517645ead5ea22c69d2a44694baa23fe1ce7c2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52708 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mmc: mmc_spi: fix error handling in mmc_spi_probe() If mmc_add_host() fails, it doesn't need to call mmc_remove_host(), or it will cause null-ptr-deref, because of deleting a not added device in mmc_remove_host(). To fix this, goto label 'fail_glue_init', if mmc_add_host() fails, and change the label 'fail_add_host' to 'fail_gpiod_request'. | ["https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be","https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f","https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714","https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd","https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3","https://git.kernel.org/stable/c/0b3edcb24bd81b3b2e3dac89f4733bfd47d283be","https://git.kernel.org/stable/c/82645bf4ed02abe930a659c5fe16d593a6dbd93f","https://git.kernel.org/stable/c/cf4c9d2ac1e42c7d18b921bec39486896645b714","https://git.kernel.org/stable/c/e9b488d60f51ae312006e224e03a30a151c28bdd","https://git.kernel.org/stable/c/ecad2fafd424ffdc203b2748ded0b37e4bbecef3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52808 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs If init debugfs failed during device registration due to memory allocation failure, debugfs_remove_recursive() is called, after which debugfs_dir is not set to NULL. debugfs_remove_recursive() will be called again during device removal. As a result, illegal pointer is accessed. [ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs! ... [ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 1669.872669] pc : down_write+0x24/0x70 [ 1669.876315] lr : down_write+0x1c/0x70 [ 1669.879961] sp : ffff000036f53a30 [ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8 [ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000 [ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270 [ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8 [ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310 [ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10 [ 1669.914982] x17: 0000000000000000 x16: 0000000000000000 [ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870 [ 1669.925555] x13: 0000000000000040 x12: 0000000000000228 [ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0 [ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10 [ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff [ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00 [ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000 [ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001 [ 1669.962563] Call trace: [ 1669.965000] down_write+0x24/0x70 [ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0 [ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main] [ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw] [ 1669.984175] pci_device_remove+0x48/0xd8 [ 1669.988082] device_release_driver_internal+0x1b4/0x250 [ 1669.993282] device_release_driver+0x28/0x38 [ 1669.997534] pci_stop_bus_device+0x84/0xb8 [ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40 [ 1670.007244] remove_store+0xfc/0x140 [ 1670.010802] dev_attr_store+0x44/0x60 [ 1670.014448] sysfs_kf_write+0x58/0x80 [ 1670.018095] kernfs_fop_write+0xe8/0x1f0 [ 1670.022000] __vfs_write+0x60/0x190 [ 1670.025472] vfs_write+0xac/0x1c0 [ 1670.028771] ksys_write+0x6c/0xd8 [ 1670.032071] __arm64_sys_write+0x24/0x30 [ 1670.035977] el0_svc_common+0x78/0x130 [ 1670.039710] el0_svc_handler+0x38/0x78 [ 1670.043442] el0_svc+0x8/0xc To fix this, set debugfs_dir to NULL after debugfs_remove_recursive(). | ["https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec","https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be","https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db","https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be","https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3","https://git.kernel.org/stable/c/33331b265aac9441ac0c1a5442e3f05d038240ec","https://git.kernel.org/stable/c/6de426f9276c448e2db7238911c97fb157cb23be","https://git.kernel.org/stable/c/75a2656260fe8c7eeabda6ff4600b29e183f48db","https://git.kernel.org/stable/c/b4465009e7d60c6111946db4c8f1e50d401ed7be","https://git.kernel.org/stable/c/f0bfc8a5561fb0b2c48183dcbfe00bdd6d973bd3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52811 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Remove BUG_ON in the case of an empty event pool In practice the driver should never send more commands than are allocated to a queue's event pool. In the unlikely event that this happens, the code asserts a BUG_ON, and in the case that the kernel is not configured to crash on panic returns a junk event pointer from the empty event list causing things to spiral from there. This BUG_ON is a historical artifact of the ibmvfc driver first being upstreamed, and it is well known now that the use of BUG_ON is bad practice except in the most unrecoverable scenario. There is nothing about this scenario that prevents the driver from recovering and carrying on. Remove the BUG_ON in question from ibmvfc_get_event() and return a NULL pointer in the case of an empty event pool. Update all call sites to ibmvfc_get_event() to check for a NULL pointer and perfrom the appropriate failure or recovery action. | ["https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4","https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d","https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f","https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8","https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0","https://git.kernel.org/stable/c/88984ec4792766df5a9de7a2ff2b5f281f94c7d4","https://git.kernel.org/stable/c/8bbe784c2ff28d56ca0c548aaf3e584edc77052d","https://git.kernel.org/stable/c/b39f2d10b86d0af353ea339e5815820026bca48f","https://git.kernel.org/stable/c/d2af4ef80601224b90630c1ddc7cd2c7c8ab4dd8","https://git.kernel.org/stable/c/e1d1f79b1929dce470a5dc9281c574cd58e8c6c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52849 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cxl/mem: Fix shutdown order Ira reports that removing cxl_mock_mem causes a crash with the following trace: BUG: kernel NULL pointer dereference, address: 0000000000000044 [..] RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core] [..] Call Trace: <TASK> cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x29/0x40 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 device_unregister+0x13/0x60 devm_release_action+0x4d/0x90 ? __pfx_unregister_port+0x10/0x10 [cxl_core] delete_endpoint+0x121/0x130 [cxl_core] devres_release_all+0xb8/0x110 device_unbind_cleanup+0xe/0x70 device_release_driver_internal+0x1d2/0x210 bus_remove_device+0xd7/0x150 device_del+0x155/0x3e0 ? lock_release+0x142/0x290 cdev_device_del+0x15/0x50 cxl_memdev_unregister+0x54/0x70 [cxl_core] This crash is due to the clearing out the cxl_memdev's driver context (@cxlds) before the subsystem is done with it. This is ultimately due to the region(s), that this memdev is a member, being torn down and expecting to be able to de-reference @cxlds, like here: static int cxl_region_decode_reset(struct cxl_region *cxlr, int count) ... if (cxlds->rcd) goto endpoint_reset; ... Fix it by keeping the driver context valid until memdev-device unregistration, and subsequently the entire stack of related dependencies, unwinds. | ["https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c","https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f","https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b","https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209","https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae","https://git.kernel.org/stable/c/0ca074f7d788627a4e0b047ca5fbdb5fc567220c","https://git.kernel.org/stable/c/20bd0198bebdd706bd4614b3933ef70d7c19618f","https://git.kernel.org/stable/c/7c7371b41a14e86f53e7dbe5baa7b1d3e0ab324b","https://git.kernel.org/stable/c/88d3917f82ed4215a2154432c26de1480a61b209","https://git.kernel.org/stable/c/cad22a757029c3a1985c221a2d4a6491ad4035ae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52856 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: lt8912b: Fix crash on bridge detach The lt8912b driver, in its bridge detach function, calls drm_connector_unregister() and drm_connector_cleanup(). drm_connector_unregister() should be called only for connectors explicitly registered with drm_connector_register(), which is not the case in lt8912b. The driver's drm_connector_funcs.destroy hook is set to drm_connector_cleanup(). Thus the driver should not call either drm_connector_unregister() nor drm_connector_cleanup() in its lt8912_bridge_detach(), as they cause a crash on bridge detach: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000858f3000 [0000000000000000] pgd=0800000085918003, p4d=0800000085918003, pud=0800000085431003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Modules linked in: tidss(-) display_connector lontium_lt8912b tc358768 panel_lvds panel_simple drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks CPU: 3 PID: 462 Comm: rmmod Tainted: G W 6.5.0-rc2+ #2 Hardware name: Toradex Verdin AM62 on Verdin Development Board (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_connector_cleanup+0x78/0x2d4 [drm] lr : lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] sp : ffff800082ed3a90 x29: ffff800082ed3a90 x28: ffff0000040c1940 x27: 0000000000000000 x26: 0000000000000000 x25: dead000000000122 x24: dead000000000122 x23: dead000000000100 x22: ffff000003fb6388 x21: 0000000000000000 x20: 0000000000000000 x19: ffff000003fb6260 x18: fffffffffffe56e8 x17: 0000000000000000 x16: 0010000000000000 x15: 0000000000000038 x14: 0000000000000000 x13: ffff800081914b48 x12: 000000000000040e x11: 000000000000015a x10: ffff80008196ebb8 x9 : ffff800081914b48 x8 : 00000000ffffefff x7 : ffff0000040c1940 x6 : ffff80007aa649d0 x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffff80008159e008 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: drm_connector_cleanup+0x78/0x2d4 [drm] lt8912_bridge_detach+0x54/0x6c [lontium_lt8912b] drm_bridge_detach+0x44/0x84 [drm] drm_encoder_cleanup+0x40/0xb8 [drm] drmm_encoder_alloc_release+0x1c/0x30 [drm] drm_managed_release+0xac/0x148 [drm] drm_dev_put.part.0+0x88/0xb8 [drm] devm_drm_dev_init_release+0x14/0x24 [drm] devm_action_release+0x14/0x20 release_nodes+0x5c/0x90 devres_release_all+0x8c/0xe0 device_unbind_cleanup+0x18/0x68 device_release_driver_internal+0x208/0x23c driver_detach+0x4c/0x94 bus_remove_driver+0x70/0xf4 driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 tidss_platform_driver_exit+0x18/0xb2c [tidss] __arm64_sys_delete_module+0x1a0/0x2b4 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x60/0x10c do_el0_svc_compat+0x1c/0x40 el0_svc_compat+0x40/0xac el0t_32_sync_handler+0xb0/0x138 el0t_32_sync+0x194/0x198 Code: 9104a276 f2fbd5b7 aa0203e1 91008af8 (f85c0420) | ["https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e","https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347","https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a","https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6","https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e","https://git.kernel.org/stable/c/42071feab712ba2a139b8928f7e0f8d3a6fc719e","https://git.kernel.org/stable/c/44283993144a03af9df31934d6c32bbd42d1a347","https://git.kernel.org/stable/c/7bf0cb8f40280a85034990dfe42be8ca8f80f37a","https://git.kernel.org/stable/c/b65e3249f3ca96e3c736af889461d80d675feab6","https://git.kernel.org/stable/c/fcd9895e365474709844eeb31cfe53d912c3596e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35851 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: qca: fix NULL-deref on non-serdev suspend Qualcomm ROME controllers can be registered from the Bluetooth line discipline and in this case the HCI UART serdev pointer is NULL. Add the missing sanity check to prevent a NULL-pointer dereference when wakeup() is called for a non-serdev controller during suspend. Just return true for now to restore the original behaviour and address the crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657 ("Bluetooth: hci_qca: only assign wakeup with serial port support") that causes the crash to happen already at setup() time. | ["https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489","https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88","https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371","https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189","https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d","https://git.kernel.org/stable/c/52f9041deaca3fc5c40ef3b9cb943993ec7d2489","https://git.kernel.org/stable/c/6b47cdeb786c38e4174319218db3fa6d7b4bba88","https://git.kernel.org/stable/c/73e87c0a49fda31d7b589edccf4c72e924411371","https://git.kernel.org/stable/c/b64092d2f108f0cd1d7fd7e176f5fb2a67a2f189","https://git.kernel.org/stable/c/e60502b907be350c518819297b565007a94c706d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35907 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxbf_gige: call request_irq() after NAPI initialized The mlxbf_gige driver encounters a NULL pointer exception in mlxbf_gige_open() when kdump is enabled. The sequence to reproduce the exception is as follows: a) enable kdump b) trigger kdump via "echo c > /proc/sysrq-trigger" c) kdump kernel executes d) kdump kernel loads mlxbf_gige module e) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought up f) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac el0_svc+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- The exception happens because there is a pending RX interrupt before the call to request_irq(RX IRQ) executes. Then, the RX IRQ handler fires immediately after this request_irq() completes. The ---truncated--- | ["https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab","https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e","https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52","https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3","https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc","https://git.kernel.org/stable/c/24444af5ddf729376b90db0f135fa19973cb5dab","https://git.kernel.org/stable/c/867a2f598af6a645c865d1101b58c5e070c6dd9e","https://git.kernel.org/stable/c/8feb1652afe9c5d019059a55c90f70690dce0f52","https://git.kernel.org/stable/c/a583117668ddb86e98f2e11c7caa3db0e6df52a3","https://git.kernel.org/stable/c/f7442a634ac06b953fc1f7418f307b25acd4cfbc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38543 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: lib/test_hmm.c: handle src_pfns and dst_pfns allocation failure The kcalloc() in dmirror_device_evict_chunk() will return null if the physical memory has run out. As a result, if src_pfns or dst_pfns is dereferenced, the null pointer dereference bug will happen. Moreover, the device is going away. If the kcalloc() fails, the pages mapping a chunk could not be evicted. So add a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, Switch kcalloc() to kvcalloc() in order to avoid failing allocations. | ["https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64","https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc","https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33","https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3","https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7","https://git.kernel.org/stable/c/1a21fdeea502658e315bd939409b755974f4fb64","https://git.kernel.org/stable/c/3b20d18f475bd17309db640dbe7d7c7ebb5bc2bc","https://git.kernel.org/stable/c/65e528a69cb3ed4a286c45b4afba57461c8b5b33","https://git.kernel.org/stable/c/c2af060d1c18beaec56351cf9c9bcbbc5af341a3","https://git.kernel.org/stable/c/ce47e8ead9a72834cc68431d53f8092ce69bebb7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39466 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/qcom/lmh: Check for SCM availability at probe Up until now, the necessary scm availability check has not been performed, leading to possible null pointer dereferences (which did happen for me on RB1). Fix that. | ["https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464","https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3","https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665","https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b","https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be","https://git.kernel.org/stable/c/0a47ba94ec3d8f782b33e3d970cfcb769b962464","https://git.kernel.org/stable/c/2226b145afa5e13cb60dbe77fb20fb0666a1caf3","https://git.kernel.org/stable/c/560d69c975072974c11434ca6953891e74c1a665","https://git.kernel.org/stable/c/aa1a0807b4a76b44fb6b58a7e9087cd4b18ab41b","https://git.kernel.org/stable/c/d9d3490c48df572edefc0b64655259eefdcbb9be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41048 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: skmsg: Skip zero length skb in sk_msg_recvmsg When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch platform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...] This crash happens every time when running sockmap_skb_verdict_shutdown subtest in sockmap_basic. This crash is because a NULL pointer is passed to page_address() in the sk_msg_recvmsg(). Due to the different implementations depending on the architecture, page_address(NULL) will trigger a panic on Loongarch platform but not on x86 platform. So this bug was hidden on x86 platform for a while, but now it is exposed on Loongarch platform. The root cause is that a zero length skb (skb->len == 0) was put on the queue. This zero length skb is a TCP FIN packet, which was sent by shutdown(), invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR); In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no page is put to this sge (see sg_set_page in sg_set_page), but this empty sge is queued into ingress_msg list. And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it to kmap_local_page() and to page_address(), then kernel panics. To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(), if copy is zero, that means it's a zero length skb, skip invoking copy_page_to_iter(). We are using the EFAULT return triggered by copy_page_to_iter to check for is_fin in tcp_bpf.c. | ["https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632","https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc","https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b","https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97","https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d","https://git.kernel.org/stable/c/195b7bcdfc5adc5b2468f279dd9eb7eebd2e7632","https://git.kernel.org/stable/c/b180739b45a38b4caa88fe16bb5273072e6613dc","https://git.kernel.org/stable/c/f0c18025693707ec344a70b6887f7450bf4c826b","https://git.kernel.org/stable/c/f8bd689f37f4198a4c61c4684f591ba639595b97","https://git.kernel.org/stable/c/fb61d7b9fb6ef0032de469499a54dab4c7260d0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42297 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't dirty inode for readonly filesystem syzbot reports f2fs bug as below: kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE) - umount - kill_f2fs_super - kill_block_super - generic_shutdown_super - sync_filesystem : sb is readonly, skip sync_filesystem() - evict_inodes - iput - f2fs_evict_inode - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode(). | ["https://git.kernel.org/stable/c/192b8fb8d1c8ca3c87366ebbef599fa80bb626b8","https://git.kernel.org/stable/c/2434344559f6743efb3ac15d11af9a0db9543bd3","https://git.kernel.org/stable/c/2d2916516577f2239b3377d9e8d12da5e6ccdfcf","https://git.kernel.org/stable/c/54162974aea37a8cae00742470a78c7f6bd6f915","https://git.kernel.org/stable/c/54bc4e88447e385c4d4ffa85d93e0dce628fcfa6","https://git.kernel.org/stable/c/9ce8135accf103f7333af472709125878704fdd4","https://git.kernel.org/stable/c/e62ff092a42f4a1bae3b310cf46673b4f3aac3b5","https://git.kernel.org/stable/c/ec56571b4b146a1cfbedab49d5fcaf19fe8bf4f1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43908 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the null pointer dereference to ras_manager Check ras_manager before using it | ["https://git.kernel.org/stable/c/033187a70ba9743c73a810a006816e5553d1e7d4","https://git.kernel.org/stable/c/48cada0ac79e4775236d642e9ec5998a7c7fb7a4","https://git.kernel.org/stable/c/4c11d30c95576937c6c35e6f29884761f2dddb43","https://git.kernel.org/stable/c/56e848034ccabe44e8f22ffcf49db771c17b0d0a","https://git.kernel.org/stable/c/b89616333979114bb0da5fa40fb6e4a2f5294ca2","https://git.kernel.org/stable/c/d81c1eeb333d84b3012a91c0500189dc1d71e46c","https://git.kernel.org/stable/c/ff5c4eb71ee8951c789b079f6e948f86708b04ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48688 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i40e: Fix kernel crash during module removal The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel crash. Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0 offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host# modprobe -r irdma Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [ 8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I 5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286] Call Trace: [ 8687.910737] <TASK> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040] pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188] driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693] pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e] Two offline tests cause IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL. During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is NULL -> crash. Do not remove client instance when client open callbacks fails and just clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only when __I40E_CLIENT_INSTANCE_OPENED is set. | ["https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae","https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc","https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9","https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc","https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746","https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520","https://git.kernel.org/stable/c/2ed94383f3a2693dbf5bc47c514b42524bd8f9ae","https://git.kernel.org/stable/c/342d77769a6cceb3df7720a1e18baa4339eee3fc","https://git.kernel.org/stable/c/38af35bec59a8431a1eb29da994a0a45cba275d9","https://git.kernel.org/stable/c/5332a094514852d5e58c278cf4193adb937337fc","https://git.kernel.org/stable/c/c49f320e2492738d478bc427dcd54ccfe0cba746","https://git.kernel.org/stable/c/fb8396aeda5872369a8ed6d2301e2c86e303c520"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52646 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: aio: fix mremap after fork null-deref Commit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduced a null-deref if mremap is called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [jmoyer@redhat.com: fix 80 column issue] | ["https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1","https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2","https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95","https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1","https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d","https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f","https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22","https://git.kernel.org/stable/c/178993157e8c50aef7f35d7d6d3b44bb428199e1","https://git.kernel.org/stable/c/4326d0080f7e84fba775da41d158f46cf9d3f1c2","https://git.kernel.org/stable/c/808f1e4b5723ae4eda724d2ad6f6638905eefd95","https://git.kernel.org/stable/c/81e9d6f8647650a7bead74c5f926e29970e834d1","https://git.kernel.org/stable/c/af126acf01a12bdb04986fd26fc2eb3b40249e0d","https://git.kernel.org/stable/c/c261f798f7baa8080cf0214081d43d5f86bb073f","https://git.kernel.org/stable/c/d8dca1bfe9adcae38b35add64977818c0c13dd22"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52705 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix underflow in second superblock position calculations Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second superblock, underflows when the argument device size is less than 4096 bytes. Therefore, when using this macro, it is necessary to check in advance that the device size is not less than a lower limit, or at least that underflow does not occur. The current nilfs2 implementation lacks this check, causing out-of-bound block access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024) In addition, when trying to resize the filesystem to a size below 4096 bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number of segments to nilfs_sufile_resize(), corrupting parameters such as the number of segments in superblocks. This causes excessive loop iterations in nilfs_sufile_resize() during a subsequent resize ioctl, causing semaphore ns_segctor_sem to block for a long time and hang the writer thread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> ... Call Trace: <TASK> folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ... This fixes these issues by inserting appropriate minimum device size checks or anti-underflow checks, depending on where the macro is used. | ["https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5","https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b","https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f","https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d","https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205","https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4","https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff","https://git.kernel.org/stable/c/0ee5ed0126a2211f7174492da2ca2c29f43755c5","https://git.kernel.org/stable/c/2f7a1135b202977b82457adde7db6c390056863b","https://git.kernel.org/stable/c/52844d8382cd9166d708032def8905ffc3ae550f","https://git.kernel.org/stable/c/99b9402a36f0799f25feee4465bfa4b8dfa74b4d","https://git.kernel.org/stable/c/a158782b56b070485d54d25fc9aaf2c8f3752205","https://git.kernel.org/stable/c/a8ef5109f93cea9933bbac0455d8c18757b3fcb4","https://git.kernel.org/stable/c/b96591e2c35c8b47db0ec816b5fc6cb8868000ff"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52869 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pstore/platform: Add check for kstrdup Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a","https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688","https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9","https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c","https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f","https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f","https://git.kernel.org/stable/c/1c426da79f9fc7b761021b5eb44185ba119cd44a","https://git.kernel.org/stable/c/379b120e4f27fd1cf636a5f85570c4d240a3f688","https://git.kernel.org/stable/c/63f637309baadf81a095f2653e3b807d4b5814b9","https://git.kernel.org/stable/c/a19d48f7c5d57c0f0405a7d4334d1d38fe9d3c1c","https://git.kernel.org/stable/c/ad5cb6deb41417ef41b9d6ff54f789212108606f","https://git.kernel.org/stable/c/bb166bdae1a7d7db30e9be7e6ccaba606debc05f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2014-8171 | Medium | N/A | The memory resource controller (aka memcg) in the Linux kernel allows local users to cause a denial of service (deadlock) by spawning new processes within a memory-constrained cgroup. | ["http://rhn.redhat.com/errata/RHSA-2015-0864.html","http://rhn.redhat.com/errata/RHSA-2015-2152.html","http://rhn.redhat.com/errata/RHSA-2015-2411.html","http://rhn.redhat.com/errata/RHSA-2016-0068.html","http://www.securityfocus.com/bid/74293","https://bugzilla.redhat.com/show_bug.cgi?id=1198109","http://rhn.redhat.com/errata/RHSA-2015-0864.html","http://rhn.redhat.com/errata/RHSA-2015-2152.html","http://rhn.redhat.com/errata/RHSA-2015-2411.html","http://rhn.redhat.com/errata/RHSA-2016-0068.html","http://www.securityfocus.com/bid/74293","https://bugzilla.redhat.com/show_bug.cgi?id=1198109"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-21803 | High | fixed |
|
Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1. | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=8081","https://bugzilla.openanolis.cn/show_bug.cgi?id=8081"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42114 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31. We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM") watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated--- | ["https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22","https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec","https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53","https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa","https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993","https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7","https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993","https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42131 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: avoid overflows in dirty throttling logic The dirty throttling logic is interspersed with assumptions that dirty limits in PAGE_SIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirty_bytes / dirty_background_bytes interfaces we can just refuse to set so large limits. For dirty_ratio / dirty_background_ratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINT_MAX. This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB. | ["https://git.kernel.org/stable/c/2b2d2b8766db028bd827af34075f221ae9e9efff","https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2","https://git.kernel.org/stable/c/4d3817b64eda07491bdd86a234629fe0764fb42a","https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290","https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805","https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2","https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0","https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc","https://git.kernel.org/stable/c/385d838df280eba6c8680f9777bfa0d0bfe7e8b2","https://git.kernel.org/stable/c/7a49389771ae7666f4dc3426e2a4594bf23ae290","https://git.kernel.org/stable/c/8e0b5e7f2895eccef5c2a0018b589266f90c4805","https://git.kernel.org/stable/c/a25e8536184516b55ef89ab91dd2eea429de28d2","https://git.kernel.org/stable/c/bd16a7ee339aef3ee4c90cb23902afb6af379ea0","https://git.kernel.org/stable/c/c83ed422c24f0d4b264f89291d4fabe285f80dbc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50247 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off. | ["https://git.kernel.org/stable/c/1b6bc5f7212181093b6c5310eea216fc09c721a9","https://git.kernel.org/stable/c/4a4727bc582832f354e0d3d49838a401a28ae25e","https://git.kernel.org/stable/c/5f21e3e60982cd7353998b4f59f052134fd47d64","https://git.kernel.org/stable/c/9931122d04c6d431b2c11b5bb7b10f28584067f0","https://git.kernel.org/stable/c/e5ae7859008688626b4d2fa6139eeaa08e255053"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2006-2932 | Medium | N/A | A regression error in the restore_all code path of the 4/4GB split support for non-hugemem Linux kernels on Red Hat Linux Desktop and Enterprise Linux 4 allows local users to cause a denial of service (panic) via unspecified vectors. | ["http://secunia.com/advisories/21605","http://secunia.com/advisories/22174","http://support.avaya.com/elmodocs2/security/ASA-2006-203.htm","http://www.osvdb.org/28120","http://www.redhat.com/support/errata/RHSA-2006-0617.html","http://www.securityfocus.com/bid/19664","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11410","http://secunia.com/advisories/21605","http://secunia.com/advisories/22174","http://support.avaya.com/elmodocs2/security/ASA-2006-203.htm","http://www.osvdb.org/28120","http://www.redhat.com/support/errata/RHSA-2006-0617.html","http://www.securityfocus.com/bid/19664","https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A11410"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45003 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfs: Don't evict inode under the inode lru traversing context The inode reclaiming process(See function prune_icache_sb) collects all reclaimable inodes and mark them with I_FREEING flag at first, at that time, other processes will be stuck if they try getting these inodes (See function find_inode_fast), then the reclaiming process destroy the inodes by function dispose_list(). Some filesystems(eg. ext4 with ea_inode feature, ubifs with xattr) may do inode lookup in the inode evicting callback function, if the inode lookup is operated under the inode lru traversing context, deadlock problems may happen. Case 1: In function ext4_evict_inode(), the ea inode lookup could happen if ea_inode feature is enabled, the lookup process will be stuck under the evicting context like this: 1. File A has inode i_reg and an ea inode i_ea 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru->i_ea 3. Then, following three processes running like this: PA PB echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // i_reg is added into lru, lru->i_ea->i_reg prune_icache_sb list_lru_walk_one inode_lru_isolate i_ea->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(i_reg) spin_unlock(&i_reg->i_lock) spin_unlock(lru_lock) rm file A i_reg->nlink = 0 iput(i_reg) // i_reg->nlink is 0, do evict ext4_evict_inode ext4_xattr_delete_inode ext4_xattr_inode_dec_ref_all ext4_xattr_inode_iget ext4_iget(i_ea->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(i_ea) ----→ AA deadlock dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&i_ea->i_state) Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file deleting process holds BASEHD's wbuf->io_mutex while getting the xattr inode, which could race with inode reclaiming process(The reclaiming process could try locking BASEHD's wbuf->io_mutex in inode evicting function), then an ABBA deadlock problem would happen as following: 1. File A has inode ia and a xattr(with inode ixa), regular file B has inode ib and a xattr. 2. getfattr(A, xattr_buf) // ixa is added into lru // lru->ixa 3. Then, following three processes running like this: PA PB PC echo 2 > /proc/sys/vm/drop_caches shrink_slab prune_dcache_sb // ib and ia are added into lru, lru->ixa->ib->ia prune_icache_sb list_lru_walk_one inode_lru_isolate ixa->i_state |= I_FREEING // set inode state inode_lru_isolate __iget(ib) spin_unlock(&ib->i_lock) spin_unlock(lru_lock) rm file B ib->nlink = 0 rm file A iput(ia) ubifs_evict_inode(ia) ubifs_jnl_delete_inode(ia) ubifs_jnl_write_inode(ia) make_reservation(BASEHD) // Lock wbuf->io_mutex ubifs_iget(ixa->i_ino) iget_locked find_inode_fast __wait_on_freeing_inode(ixa) | iput(ib) // ib->nlink is 0, do evict | ubifs_evict_inode | ubifs_jnl_delete_inode(ib) ↓ ubifs_jnl_write_inode ABBA deadlock ←-----make_reservation(BASEHD) dispose_list // cannot be executed by prune_icache_sb wake_up_bit(&ixa->i_state) Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING to pin the inode in memory while inode_lru_isolate( ---truncated--- | ["https://git.kernel.org/stable/c/03880af02a78bc9a98b5a581f529cf709c88a9b8","https://git.kernel.org/stable/c/2a0629834cd82f05d424bbc193374f9a43d1f87d","https://git.kernel.org/stable/c/3525ad25240dfdd8c78f3470911ed10aa727aa72","https://git.kernel.org/stable/c/437741eba63bf4e437e2beb5583f8633556a2b98","https://git.kernel.org/stable/c/9063ab49c11e9518a3f2352434bb276cc8134c5f","https://git.kernel.org/stable/c/b9bda5f6012dd00372f3a06a82ed8971a4c57c32","https://git.kernel.org/stable/c/cda54ec82c0f9d05393242b20b13f69b083f7e88"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39474 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") includes support for __GFP_NOFAIL, but it presents a conflict with commit dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A possible scenario is as follows: process-a __vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) __vmalloc_area_node() vm_area_alloc_pages() --> oom-killer send SIGKILL to process-a if (fatal_signal_pending(current)) break; --> return NULL; To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() if __GFP_NOFAIL set. This issue occurred during OPLUS KASAN TEST. Below is part of the log -> oom-killer sends signal to process [65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 [65731.259685] [T32454] Call trace: [65731.259698] [T32454] dump_backtrace+0xf4/0x118 [65731.259734] [T32454] show_stack+0x18/0x24 [65731.259756] [T32454] dump_stack_lvl+0x60/0x7c [65731.259781] [T32454] dump_stack+0x18/0x38 [65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] [65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] [65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc [65731.260047] [T32454] notify_die+0x114/0x198 [65731.260073] [T32454] die+0xf4/0x5b4 [65731.260098] [T32454] die_kernel_fault+0x80/0x98 [65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 [65731.260146] [T32454] do_bad_area+0x68/0x148 [65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 [65731.260204] [T32454] el1_abort+0x3c/0x5c [65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 [65731.260248] [T32454] el1h_64_sync+0x68/0x6c [65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 --> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); kernel panic by NULL pointer dereference. erofs assume kvmalloc with __GFP_NOFAIL never return NULL. [65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c [65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 [65731.260339] [T32454] read_pages+0x170/0xadc [65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 [65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 [65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 [65731.260437] [T32454] __do_fault+0xd0/0x33c [65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 [65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 [65731.260509] [T32454] el0_da+0x44/0x94 [65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 [65731.260553] [T32454] el0t_64_sync+0x198/0x19c | ["https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91","https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4","https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc","https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da","https://git.kernel.org/stable/c/198a80833e3421d4c9820a4ae907120adf598c91","https://git.kernel.org/stable/c/758678b65164b2158fc1de411092191cb3c394d4","https://git.kernel.org/stable/c/8e0545c83d672750632f46e3f9ad95c48c91a0fc","https://git.kernel.org/stable/c/c55d3564ad25ce87ab7cc6af251f9574faebd8da"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40973 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: mtk-vcodec: potential null pointer deference in SCP The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113. | ["https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b","https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b","https://git.kernel.org/stable/c/eeb62bb4ca22db17f7dfe8fb8472e0442df3d92f","https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354","https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b","https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b","https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41001 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: work around a potential audit memory leak kmemleak complains that there's a memory leak related to connect handling: unreferenced object 0xffff0001093bdf00 (size 128): comm "iou-sqp-455", pid 457, jiffies 4294894164 hex dump (first 32 bytes): 02 00 fa ea 7f 00 00 01 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 2e481b1a): [<00000000c0a26af4>] kmemleak_alloc+0x30/0x38 [<000000009c30bb45>] kmalloc_trace+0x228/0x358 [<000000009da9d39f>] __audit_sockaddr+0xd0/0x138 [<0000000089a93e34>] move_addr_to_kernel+0x1a0/0x1f8 [<000000000b4e80e6>] io_connect_prep+0x1ec/0x2d4 [<00000000abfbcd99>] io_submit_sqes+0x588/0x1e48 [<00000000e7c25e07>] io_sq_thread+0x8a4/0x10e4 [<00000000d999b491>] ret_from_fork+0x10/0x20 which can can happen if: 1) The command type does something on the prep side that triggers an audit call. 2) The thread hasn't done any operations before this that triggered an audit call inside ->issue(), where we have audit_uring_entry() and audit_uring_exit(). Work around this by issuing a blanket NOP operation before the SQPOLL does anything. | ["https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227","https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667","https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3","https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae","https://git.kernel.org/stable/c/55c22375cbaa24f77dd13f9ae0642915444a1227","https://git.kernel.org/stable/c/9e810bd995823786ea30543e480e8a573e5e5667","https://git.kernel.org/stable/c/a40e90d9304629002fb17200f7779823a81191d3","https://git.kernel.org/stable/c/c4ce0ab27646f4206a9eb502d6fe45cb080e1cae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36288 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix loop termination condition in gss_free_in_token_pages() The in_token->pages[] array is not NULL terminated. This results in the following KASAN splat: KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f] | ["https://git.kernel.org/stable/c/0a1cb0c6102bb4fd310243588d39461da49497ad","https://git.kernel.org/stable/c/4a77c3dead97339478c7422eb07bf4bf63577008","https://git.kernel.org/stable/c/4cefcd0af7458bdeff56a9d8dfc6868ce23d128a","https://git.kernel.org/stable/c/57ff6c0a175930856213b2aa39f8c845a53e5b1c","https://git.kernel.org/stable/c/6ed45d20d30005bed94c8c527ce51d5ad8121018","https://git.kernel.org/stable/c/af628d43a822b78ad8d4a58d8259f8bf8bc71115","https://git.kernel.org/stable/c/b4878ea99f2b40ef1925720b1b4ca7f4af1ba785","https://git.kernel.org/stable/c/f9977e4e0cd98a5f06f2492b4f3547db58deabf5","https://git.kernel.org/stable/c/0a1cb0c6102bb4fd310243588d39461da49497ad","https://git.kernel.org/stable/c/4a77c3dead97339478c7422eb07bf4bf63577008","https://git.kernel.org/stable/c/4cefcd0af7458bdeff56a9d8dfc6868ce23d128a","https://git.kernel.org/stable/c/57ff6c0a175930856213b2aa39f8c845a53e5b1c","https://git.kernel.org/stable/c/6ed45d20d30005bed94c8c527ce51d5ad8121018","https://git.kernel.org/stable/c/af628d43a822b78ad8d4a58d8259f8bf8bc71115","https://git.kernel.org/stable/c/b4878ea99f2b40ef1925720b1b4ca7f4af1ba785","https://git.kernel.org/stable/c/f9977e4e0cd98a5f06f2492b4f3547db58deabf5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49963 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs | ["https://git.kernel.org/stable/c/10a58555e0bb5cc4673c8bb73b8afc5fa651f0ac","https://git.kernel.org/stable/c/32ee78823dea2d54adaf6e05f86622eba359e091","https://git.kernel.org/stable/c/4e1e03760ee7cc4779b6306867fe0fc02921b963","https://git.kernel.org/stable/c/90320cfc07b7d6e7a58fd8168f6380ec52ff0251","https://git.kernel.org/stable/c/b0de20de29b13950493a36bd4cf531200eb0e807","https://git.kernel.org/stable/c/dc09f007caed3b2f6a3b6bd7e13777557ae22bfd","https://git.kernel.org/stable/c/df293ea78740a41384d648041f38f645700288e1","https://git.kernel.org/stable/c/dfeb67b2194ecc55ef8065468c5adda3cdf59114","https://git.kernel.org/stable/c/e65a9af05a0b59ebeba28e5e82265a233db7bc27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50233 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value. | ["https://git.kernel.org/stable/c/2f39548f45693d86e950647012a214da6917dc9f","https://git.kernel.org/stable/c/442f786c5bff8cfd756ebdeaa4aadbf05c22aa5a","https://git.kernel.org/stable/c/6bd301819f8f69331a55ae2336c8b111fc933f3d","https://git.kernel.org/stable/c/adfbc08b94e7df08b9ed5fa26b969cc1b54c84ec","https://git.kernel.org/stable/c/ccbc10647aafe2b7506edb4b10e19c6c2416c162","https://git.kernel.org/stable/c/dd9e1cf619c945f320e686dcaf13e37ef0b05fdd","https://git.kernel.org/stable/c/fcd6b59f7a774558e2525251c68aa37aff748e55"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50292 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid. | ["https://git.kernel.org/stable/c/0d75f887aabd80cf37ea48d28f159afa7850ea28","https://git.kernel.org/stable/c/22ae9321054cf7f36c537702af133659f51a0b88","https://git.kernel.org/stable/c/23bdbd1ef3e063e03d3c50c15a591b005ebbae39","https://git.kernel.org/stable/c/3a977b554f668382dfba31fd62e4cce4fe5643db","https://git.kernel.org/stable/c/4f1d74f74752eab8af6b8b28797dc6490d57374c","https://git.kernel.org/stable/c/9bb4af400c386374ab1047df44c508512c08c31f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35790 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group The DisplayPort driver's sysfs nodes may be present to the userspace before typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that a sysfs read can trigger a NULL pointer error by deferencing dp->hpd in hpd_show or dp->lock in pin_assignment_show, as dev_get_drvdata() returns NULL in those cases. Remove manual sysfs node creation in favor of adding attribute group as default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is not used here otherwise the path to the sysfs nodes is no longer compliant with the ABI. | ["https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9","https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531","https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0","https://git.kernel.org/stable/c/9794ffd9d0c39ee070fbd733f862bbe89b28ba33","https://git.kernel.org/stable/c/f1c5ddaef506e3517dce338c08a60663b1521920","https://git.kernel.org/stable/c/0ad011776c057ce881b7fd6d8c79ecd459c087e9","https://git.kernel.org/stable/c/165376f6b23e9a779850e750fb2eb06622e5a531","https://git.kernel.org/stable/c/4a22aeac24d0d5f26ba741408e8b5a4be6dc5dc0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: selinux: avoid dereference of garbage after mount failure In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer. While on it drop the never read static variable selinuxfs_mount. | ["https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b","https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e","https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c","http://www.openwall.com/lists/oss-security/2024/05/30/1","http://www.openwall.com/lists/oss-security/2024/05/30/2","https://git.kernel.org/stable/c/37801a36b4d68892ce807264f784d818f8d0d39b","https://git.kernel.org/stable/c/477ed6789eb9f3f4d3568bb977f90c863c12724e","https://git.kernel.org/stable/c/68784a5d01b8868ff85a7926676b6729715fff3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48673 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix possible access to freed memory in link clear After modifying the QP to the Error state, all RX WR would be completed with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not wait for it is done, but destroy the QP and free the link group directly. So there is a risk that accessing the freed memory in tasklet context. Here is a crash example: BUG: unable to handle page fault for address: ffffffff8f220860 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S OE 5.10.0-0607+ #23 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0 Code: f3 90 48 8b 32 48 85 f6 74 f6 eb d5 c1 ee 12 83 e0 03 83 ee 01 48 c1 e0 05 48 63 f6 48 05 00 c8 02 00 48 03 04 f5 00 09 98 8e <48> 89 10 8b 42 08 85 c0 75 09 f3 90 8b 42 08 85 c0 74 f7 48 8b 32 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> _raw_spin_lock_irqsave+0x30/0x40 mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib] smc_wr_rx_tasklet_fn+0x56/0xa0 [smc] tasklet_action_common.isra.21+0x66/0x100 __do_softirq+0xd5/0x29c asm_call_irq_on_stack+0x12/0x20 </IRQ> do_softirq_own_stack+0x37/0x40 irq_exit_rcu+0x9d/0xa0 sysvec_call_function_single+0x34/0x80 asm_sysvec_call_function_single+0x12/0x20 | ["https://git.kernel.org/stable/c/89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde","https://git.kernel.org/stable/c/e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968","https://git.kernel.org/stable/c/89fcb70f1acd6b0bbf2f7bfbf45d7aa75a9bdcde","https://git.kernel.org/stable/c/e9b1a4f867ae9c1dbd1d71cd09cbdb3239fb4968"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48703 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR In some case, the GDDV returns a package with a buffer which has zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10). Then the data_vault_read() got NULL point dereference problem when accessing the 0x10 value in data_vault. [ 71.024560] BUG: kernel NULL pointer dereference, address: 0000000000000010 This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or NULL value in data_vault. | ["https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d","https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2","https://git.kernel.org/stable/c/7931e28098a4c1a2a6802510b0cbe57546d2049d","https://git.kernel.org/stable/c/dae42083b045a4ddf71c57cf350cb2412b5915c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48706 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vdpa: ifcvf: Do proper cleanup if IFCVF init fails ifcvf_mgmt_dev leaks memory if it is not freed before returning. Call is made to correct return statement so memory does not leak. ifcvf_init_hw does not take care of this so it is needed to do it here. | ["https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e","https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94","https://git.kernel.org/stable/c/5d2cc32c1c10bd889125d2adc16a6bc3338dcd3e","https://git.kernel.org/stable/c/6b04456e248761cf68f562f2fd7c04e591fcac94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42139 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper extts handling Extts events are disabled and enabled by the application ts2phc. However, in case where the driver is removed when the application is running, a specific extts event remains enabled and can cause a kernel crash. As a side effect, when the driver is reloaded and application is started again, remaining extts event for the channel from a previous run will keep firing and the message "extts on unexpected channel" might be printed to the user. To avoid that, extts events shall be disabled when PTP is released. | ["https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc","https://git.kernel.org/stable/c/9f69b31ae9e25dec27ad31fbc64dd99af16ee3d3","https://git.kernel.org/stable/c/00d3b4f54582d4e4a02cda5886bb336eeab268cc","https://git.kernel.org/stable/c/9f69b31ae9e25dec27ad31fbc64dd99af16ee3d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43905 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr Check return value and conduct null pointer handling to avoid null pointer dereference. | ["https://git.kernel.org/stable/c/0fa11f9df96217c2785b040629ff1a16900fb51c","https://git.kernel.org/stable/c/2ac9deb7e087f0b461c3559d9eaa6b9cf19d3fa8","https://git.kernel.org/stable/c/2e538944996d0dd497faf8ee81f8bfcd3aca7d80","https://git.kernel.org/stable/c/50151b7f1c79a09117837eb95b76c2de76841dab","https://git.kernel.org/stable/c/69a441473fec2fc2aa2cf56122d6c42c4266a239","https://git.kernel.org/stable/c/c2629daf218a325f4d69754452cd42fe8451c15b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27002 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Do a runtime PM get on controllers during probe mt8183-mfgcfg has a mutual dependency with genpd during the probing stage, which leads to a deadlock in the following call stack: CPU0: genpd_lock --> clk_prepare_lock genpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock() CPU1: clk_prepare_lock --> genpd_lock clk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock() Do a runtime PM get at the probe function to make sure clk_register() won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg, do this on all mediatek clock controller probings because we don't believe this would cause any regression. Verified on MT8183 and MT8192 Chromebooks. | ["https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8","https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3","https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5","https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc","https://git.kernel.org/stable/c/165d226472575b213dd90dfda19d1605dd7c19a8","https://git.kernel.org/stable/c/2f7b1d8b5505efb0057cd1ab85fca206063ea4c3","https://git.kernel.org/stable/c/b62ed25feb342eab052822eff0c554873799a4f5","https://git.kernel.org/stable/c/c0dcd5c072e2a3fff886f673e6a5d9bf8090c4cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27014 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated--- | ["https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc","https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b","https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b","https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693","https://git.kernel.org/stable/c/0080bf99499468030248ebd25dd645e487dcecdc","https://git.kernel.org/stable/c/46efa4d5930cf3c2af8c01f75e0a47e4fc045e3b","https://git.kernel.org/stable/c/48c4bb81df19402d4346032353d0795260255e3b","https://git.kernel.org/stable/c/fef965764cf562f28afb997b626fc7c3cec99693"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48675 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix a nested dead lock as part of ODP flow Fix a nested dead lock as part of ODP flow by using mmput_async(). From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex. Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available. [1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] <TASK> [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? process_one_work+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? set_kthread_struct+0x50/0x50 [64843.078085] ret_from_fork+0x22/0x30 [64843.078093] </TASK> | ["https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785","https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3","https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833","https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f","https://git.kernel.org/stable/c/819110054b14d7272b4188db997a3d80f75ab785","https://git.kernel.org/stable/c/83c43fd872e32c8071d5582eb7c40f573a8342f3","https://git.kernel.org/stable/c/85eaeb5058f0f04dffb124c97c86b4f18db0b833","https://git.kernel.org/stable/c/e8de6cb5755eae7b793d8c00c8696c8667d44a7f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50154 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink(). Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler(). """ We are seeing a use-after-free from a bpf prog attached to trace_tcp_retransmit_synack. The program passes the req->sk to the bpf_sk_storage_get_tracing kernel helper which does check for null before using it. """ The commit 83fccfc3940c ("inet: fix potential deadlock in reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not to call del_timer_sync() from reqsk_timer_handler(), but it introduced a small race window. Before the timer is called, expire_timers() calls detach_timer(timer, true) to clear timer->entry.pprev and marks it as not pending. If reqsk_queue_unlink() checks timer_pending() just after expire_timers() calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires. The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default. The scenario would be 1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(), but del_timer_sync() is missed 2. reqsk timer is executed and scheduled again 3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but reqsk timer still has another one, and inet_csk_accept() does not clear req->sk for non-TFO sockets 4. sk is close()d 5. reqsk timer is executed again, and BPF touches req->sk Let's not use timer_pending() by passing the caller context to __inet_csk_reqsk_queue_drop(). Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1] [0] BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0 Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpf_sk_storage_get_tracing+0x2e/0x1b0 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda bpf_trace_run2+0x4c/0xc0 tcp_rtx_synack+0xf9/0x100 reqsk_timer_handler+0xda/0x3d0 run_timer_softirq+0x292/0x8a0 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 intel_idle_irq+0x5a/0xa0 cpuidle_enter_state+0x94/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6 allocated by task 0 on cpu 9 at 260507.901592s: sk_prot_alloc+0x35/0x140 sk_clone_lock+0x1f/0x3f0 inet_csk_clone_lock+0x15/0x160 tcp_create_openreq_child+0x1f/0x410 tcp_v6_syn_recv_sock+0x1da/0x700 tcp_check_req+0x1fb/0x510 tcp_v6_rcv+0x98b/0x1420 ipv6_list_rcv+0x2258/0x26e0 napi_complete_done+0x5b1/0x2990 mlx5e_napi_poll+0x2ae/0x8d0 net_rx_action+0x13e/0x590 irq_exit_rcu+0xf5/0x320 common_interrupt+0x80/0x90 asm_common_interrupt+0x22/0x40 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb freed by task 0 on cpu 9 at 260507.927527s: rcu_core_si+0x4ff/0xf10 irq_exit_rcu+0xf5/0x320 sysvec_apic_timer_interrupt+0x6d/0x80 asm_sysvec_apic_timer_interrupt+0x16/0x20 cpuidle_enter_state+0xfb/0x273 cpu_startup_entry+0x15e/0x260 start_secondary+0x8a/0x90 secondary_startup_64_no_verify+0xfa/0xfb | ["https://git.kernel.org/stable/c/106e457953315e476b3642ef24be25ed862aaba3","https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1","https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d","https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17","https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3","https://git.kernel.org/stable/c/c964bf65f80a14288d767023a1b300b30f5b9cd0","https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2019-3016 | Medium | N/A | In a Linux KVM guest that has PV TLB enabled, a process in the guest kernel may be able to read memory locations from another process in the same guest. This problem is limit to the host running linux kernel 4.10 with a guest running linux kernel 4.16 or later. The problem mainly affects AMD processors but Intel CPUs cannot be ruled out. | ["http://packetstormsecurity.com/files/157233/Kernel-Live-Patch-Security-Notice-LSN-0065-1.html","http://www.openwall.com/lists/oss-security/2020/01/30/4","https://bugzilla.redhat.com/show_bug.cgi?id=1792167","https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7","https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e","https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589","https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e","https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796","https://lore.kernel.org/lkml/1580407316-11391-1-git-send-email-pbonzini%40redhat.com/","https://security.netapp.com/advisory/ntap-20200313-0003/","https://usn.ubuntu.com/4300-1/","https://usn.ubuntu.com/4301-1/","https://www.debian.org/security/2020/dsa-4699","http://packetstormsecurity.com/files/157233/Kernel-Live-Patch-Security-Notice-LSN-0065-1.html","http://www.openwall.com/lists/oss-security/2020/01/30/4","https://bugzilla.redhat.com/show_bug.cgi?id=1792167","https://git.kernel.org/linus/1eff70a9abd46f175defafd29bc17ad456f398a7","https://git.kernel.org/linus/8c6de56a42e0c657955e12b882a81ef07d1d073e","https://git.kernel.org/linus/917248144db5d7320655dbb41d3af0b8a0f3d589","https://git.kernel.org/linus/a6bd811f1209fe1c64c9f6fd578101d6436c6b6e","https://git.kernel.org/linus/b043138246a41064527cf019a3d51d9f015e9796","https://lore.kernel.org/lkml/1580407316-11391-1-git-send-email-pbonzini%40redhat.com/","https://security.netapp.com/advisory/ntap-20200313-0003/","https://usn.ubuntu.com/4300-1/","https://usn.ubuntu.com/4301-1/","https://www.debian.org/security/2020/dsa-4699"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46833 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: void array out of bound when loop tnl_num When query reg inf of SSU, it loops tnl_num times. However, tnl_num comes from hardware and the length of array is a fixed value. To void array out of bound, make sure the loop time is not greater than the length of array | ["https://git.kernel.org/stable/c/86db7bfb06704ef17340eeae71c832f21cfce35c","https://git.kernel.org/stable/c/c33a9806dc806bcb4a31dc71fb06979219181ad4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46836 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed_udc: validate endpoint index for ast udc We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array. Found by static analysis. | ["https://git.kernel.org/stable/c/31bd4fab49c0adc6228848357c1b1df9395858af","https://git.kernel.org/stable/c/6fe9ca2ca389114c8da66e534c18273497843e8a","https://git.kernel.org/stable/c/b2a50ffdd1a079869a62198a8d1441355c513c7c","https://git.kernel.org/stable/c/ee0d382feb44ec0f445e2ad63786cd7f3f6a8199"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53098 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928) | ["https://git.kernel.org/stable/c/5d623ffbae96b23f1fc43a3d5a267aabdb07583d","https://git.kernel.org/stable/c/9c1813b3253480b30604c680026c7dc721ce86d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53133 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c) | ["https://git.kernel.org/stable/c/6825cb07b79ffeb1d90ffaa7a1227462cdca34ae","https://git.kernel.org/stable/c/874ff59cde8fc525112dda26b501a1bac17dde9f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4273 | Medium | fixed |
|
A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4273","https://bugzilla.redhat.com/show_bug.cgi?id=2221609","https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4273","https://bugzilla.redhat.com/show_bug.cgi?id=2221609","https://dfir.ru/2023/08/23/cve-2023-4273-a-vulnerability-in-the-linux-exfat-driver/","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/","https://security.netapp.com/advisory/ntap-20231027-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48697 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a use-after-free Fix the following use-after-free complaint triggered by blktests nvme/004: BUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350 Read of size 4 at addr 0000607bd1835943 by task kworker/13:1/460 Workqueue: nvmet-wq nvme_loop_execute_work [nvme_loop] Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x49/0x5e print_report.cold+0x36/0x1e2 kasan_report+0xb9/0xf0 __asan_load4+0x6b/0x80 blk_mq_complete_request_remote+0xac/0x350 nvme_loop_queue_response+0x1df/0x275 [nvme_loop] __nvmet_req_complete+0x132/0x4f0 [nvmet] nvmet_req_complete+0x15/0x40 [nvmet] nvmet_execute_io_connect+0x18a/0x1f0 [nvmet] nvme_loop_execute_work+0x20/0x30 [nvme_loop] process_one_work+0x56e/0xa70 worker_thread+0x2d1/0x640 kthread+0x183/0x1c0 ret_from_fork+0x1f/0x30 | ["https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e","https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060","https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52","https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717","https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b","https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa","https://git.kernel.org/stable/c/17f121ca3ec6be0fb32d77c7f65362934a38cc8e","https://git.kernel.org/stable/c/4484ce97a78171668c402e0c45db7f760aea8060","https://git.kernel.org/stable/c/6a02a61e81c231cc5c680c5dbf8665275147ac52","https://git.kernel.org/stable/c/8d66989b5f7bb28bba2f8e1e2ffc8bfef4a10717","https://git.kernel.org/stable/c/be01f1c988757b95f11f090a9f491365670a522b","https://git.kernel.org/stable/c/ebf46da50beb78066674354ad650606a467e33fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49532 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: fix NULL pointer dereference in virtio_gpu_conn_get_modes drm_cvt_mode may return NULL and we should check it. This bug is found by syzkaller: FAULT_INJECTION stacktrace: [ 168.567394] FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dump_backtrace+0x0/0x310 [ 168.567418] show_stack+0x28/0x38 [ 168.567423] dump_stack+0xec/0x15c [ 168.567427] should_fail+0x3ac/0x3d0 [ 168.567437] __should_failslab+0xb8/0x120 [ 168.567441] should_failslab+0x28/0xc0 [ 168.567445] kmem_cache_alloc_trace+0x50/0x640 [ 168.567454] drm_mode_create+0x40/0x90 [ 168.567458] drm_cvt_mode+0x48/0xc78 [ 168.567477] virtio_gpu_conn_get_modes+0xa8/0x140 [virtio_gpu] [ 168.567485] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567492] drm_mode_getconnector+0x2e0/0xa70 [ 168.567496] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567514] drm_ioctl+0x558/0x6d0 [ 168.567522] do_vfs_ioctl+0x160/0xf30 [ 168.567525] ksys_ioctl+0x98/0xd8 [ 168.567530] __arm64_sys_ioctl+0x50/0xc8 [ 168.567536] el0_svc_common+0xc8/0x320 [ 168.567540] el0_svc_handler+0xf8/0x160 [ 168.567544] el0_svc+0x10/0x218 KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dump_backtrace+0x0/0x310 [ 168.567582] show_stack+0x28/0x38 [ 168.567586] dump_stack+0xec/0x15c [ 168.567591] kasan_report+0x244/0x2f0 [ 168.567594] __asan_load4+0x58/0xb0 [ 168.567607] virtio_gpu_conn_get_modes+0xb4/0x140 [virtio_gpu] [ 168.567612] drm_helper_probe_single_connector_modes+0x3a4/0xd80 [ 168.567617] drm_mode_getconnector+0x2e0/0xa70 [ 168.567621] drm_ioctl_kernel+0x11c/0x1d8 [ 168.567624] drm_ioctl+0x558/0x6d0 [ 168.567628] do_vfs_ioctl+0x160/0xf30 [ 168.567632] ksys_ioctl+0x98/0xd8 [ 168.567636] __arm64_sys_ioctl+0x50/0xc8 [ 168.567641] el0_svc_common+0xc8/0x320 [ 168.567645] el0_svc_handler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218 | ["https://git.kernel.org/stable/c/0f8bc147a963686b7351aa35d1701124ffacac08","https://git.kernel.org/stable/c/194d250cdc4a40ccbd179afd522a9e9846957402","https://git.kernel.org/stable/c/32e10aabc287f09a148ff759bb9ce70b01b0012c","https://git.kernel.org/stable/c/848dd072744ea662ab3097e3c8282bee552df218","https://git.kernel.org/stable/c/c51d00472fa54b9b05c17789ed665c17adf3a25d","https://git.kernel.org/stable/c/e0828456578cc8ba0a69147f7ae3428392eec287","https://git.kernel.org/stable/c/edafcad84c4134ebec4bc24b29ca4497a1184eea","https://git.kernel.org/stable/c/f85cb059fad03a3b33a50023be91e944bb065ae8","https://git.kernel.org/stable/c/fadc626cae99aaa1325094edc6a9e2b883f3e562"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1263 | Medium | fixed |
|
A NULL pointer dereference issue was found in KVM when releasing a vCPU with dirty ring support enabled. This flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel oops condition that results in a denial of service. | ["https://access.redhat.com/security/cve/CVE-2022-1263","https://bugzilla.redhat.com/show_bug.cgi?id=2072698","https://github.com/torvalds/linux/commit/5593473a1e6c743764b08e3b6071cb43b5cfa6c4","https://www.openwall.com/lists/oss-security/2022/04/07/1","https://access.redhat.com/security/cve/CVE-2022-1263","https://bugzilla.redhat.com/show_bug.cgi?id=2072698","https://github.com/torvalds/linux/commit/5593473a1e6c743764b08e3b6071cb43b5cfa6c4","https://www.openwall.com/lists/oss-security/2022/04/07/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48766 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU. Mirrors the logic for dcn30. Cue lots of WARNs and some kernel panics without this fix. | ["https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f","https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341","https://git.kernel.org/stable/c/25f1488bdbba63415239ff301fe61a8546140d9f","https://git.kernel.org/stable/c/456ba2433844a6483cc4c933aa8f43d24575e341"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if the thermal zone does not define one. | ["https://git.kernel.org/stable/c/1c0b51e62a50e9291764d022ed44549e65d6ab9c","https://git.kernel.org/stable/c/3dafbf915c05f83469e791949b5590da2aca2afb","https://git.kernel.org/stable/c/4c294285cec3964b3291772ac0642c2bf440bd1b","https://git.kernel.org/stable/c/5838a14832d447990827d85e90afe17e6fb9c175"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48710 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix a possible null pointer dereference In radeon_fp_native_mode(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. The failure status of drm_cvt_mode() on the other path is checked too. | ["https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17","https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f","https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60","https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9","https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29","https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f","https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9","https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479","https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab","https://git.kernel.org/stable/c/140d9807b96e1303f6f2675a7ae8710a2094bd17","https://git.kernel.org/stable/c/16a0f0b63c4c7eb46fc4c3f00bf2836e6ee46a9f","https://git.kernel.org/stable/c/28fd384c78d7d8ed8af0d086d778c3e438ba7f60","https://git.kernel.org/stable/c/7b7fba107b2c4ec7673d0f45bdbb9d1af697d9b9","https://git.kernel.org/stable/c/8a89bfeef9abe93371e3ea8796377f2d132eee29","https://git.kernel.org/stable/c/a2b28708b645c5632dc93669ab06e97874c8244f","https://git.kernel.org/stable/c/b33f7d99c9226892c7794dc2500fae35966020c9","https://git.kernel.org/stable/c/e938d24f0b7392e142b8aa434f18590d99dbe479","https://git.kernel.org/stable/c/fee8ae0a0bb66eb7730c22f44fbd7203f63c2eab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52789 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: vcc: Add check for kstrdup() in vcc_probe() Add check for the return value of kstrdup() and return the error, if it fails in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3","https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac","https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9","https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc","https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06","https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2","https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a","https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200","https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6","https://git.kernel.org/stable/c/38cd56fc9de78bf3c878790785e8c231116ef9d3","https://git.kernel.org/stable/c/460284dfb10b207980c6f3f7046e33446ceb38ac","https://git.kernel.org/stable/c/4a24a31826246b15477399febd13292b0c9f0ee9","https://git.kernel.org/stable/c/4ef41a7f33ffe1a335e7db7e1564ddc6afad47cc","https://git.kernel.org/stable/c/6c80f48912b5bd4965352d1a9a989e21743a4a06","https://git.kernel.org/stable/c/7cebc86481bf16049e266f6774d90f2fd4f8d5d2","https://git.kernel.org/stable/c/8f8771757b130383732195497e47fba2aba76d3a","https://git.kernel.org/stable/c/909963e0c16778cec28efb1affc21558825f4200","https://git.kernel.org/stable/c/d81ffb87aaa75f842cd7aa57091810353755b3e6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52865 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478","https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3","https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c","https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4","https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836","https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2","https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf","https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235","https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92","https://git.kernel.org/stable/c/122ac6496e4975ddd7ec1edba4f6fc1e15e39478","https://git.kernel.org/stable/c/2705c5b97f504e831ae1935c05f0e44f80dfa6b3","https://git.kernel.org/stable/c/357df1c2f6ace96defd557fad709ed1f9f70e16c","https://git.kernel.org/stable/c/3aefc6fcfbada57fac27f470602d5565e5b76cb4","https://git.kernel.org/stable/c/4c79cbfb8e9e2311be77182893fda5ea4068c836","https://git.kernel.org/stable/c/606f6366a35a3329545e38129804d65ef26ed7d2","https://git.kernel.org/stable/c/81b16286110728674dcf81137be0687c5055e7bf","https://git.kernel.org/stable/c/be3f12f16038a558f08fa93cc32fa715746a5235","https://git.kernel.org/stable/c/c26feedbc561f2a3cee1a4f717e61bdbdfb4fa92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96","https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3","https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d","https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7","https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802","https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739","https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055","https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95","https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47","https://git.kernel.org/stable/c/001e5def774fa1a8f2b29567c0b0cd3e3a859a96","https://git.kernel.org/stable/c/0d6e24b422a2166a9297a8286ff2e6ab9a5e8cd3","https://git.kernel.org/stable/c/1953e62366da5460dc712e045f94fb0d8918999d","https://git.kernel.org/stable/c/1bf9c204aef4cc55ce46a7ff2d4dc7e5f86551a7","https://git.kernel.org/stable/c/2a18dd653284550900b02107c3c7b3ac5e0eb802","https://git.kernel.org/stable/c/6fccee2af400edaed9cf349d506c5971d4762739","https://git.kernel.org/stable/c/d1175cf4bd2b4c5f7c43f677ea1ce9ad2c18d055","https://git.kernel.org/stable/c/d1461f0c9ca0827c03730fe9652ebbf6316a2a95","https://git.kernel.org/stable/c/e61934720af4a58ffd43a63ffdd6f3a0bd7d7b47"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27044 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875) | ["https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7","https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0","https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7","https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08","https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb","https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484","https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656","https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a","https://git.kernel.org/stable/c/14613d52bc7fc180df6d2c65ba65fc921fc1dda7","https://git.kernel.org/stable/c/29fde8895b2fcc33f44aea28c644ce2d9b62f9e0","https://git.kernel.org/stable/c/2d9fe7787af01188dc470a649bdbb842d6511fd7","https://git.kernel.org/stable/c/330caa061af53ea6d287d7c43d0703714e510e08","https://git.kernel.org/stable/c/6ac7c7a3a9ab57aba0fe78ecb922d2b20e16efeb","https://git.kernel.org/stable/c/7874ab3105ca4657102fee1cc14b0af70883c484","https://git.kernel.org/stable/c/9ccfe80d022df7c595f1925afb31de2232900656","https://git.kernel.org/stable/c/e019d87e02f1e539ae48b99187f253847744ca7a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27059 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values in the ATA ID information to calculate cylinder and head values when creating a CDB for READ or WRITE commands. The calculation involves division and modulus operations, which will cause a crash if either of these values is 0. While this never happens with a genuine device, it could happen with a flawed or subversive emulation, as reported by the syzbot fuzzer. Protect against this possibility by refusing to bind to the device if either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID information is 0. This requires isd200_Initialization() to return a negative error code when initialization fails; currently it always returns 0 (even when there is an error). | ["https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49","https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133","https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636","https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964","https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325","https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34","https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f","https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa","https://git.kernel.org/stable/c/014bcf41d946b36a8f0b8e9b5d9529efbb822f49","https://git.kernel.org/stable/c/284fb1003d5da111019b9e0bf99b084fd71ac133","https://git.kernel.org/stable/c/3a67d4ab9e730361d183086dfb0ddd8c61f01636","https://git.kernel.org/stable/c/6c1f36d92c0a8799569055012665d2bb066fb964","https://git.kernel.org/stable/c/871fd7b10b56d280990b7e754f43d888382ca325","https://git.kernel.org/stable/c/9968c701cba7eda42e5f0052b040349d6222ae34","https://git.kernel.org/stable/c/eb7b01ca778170654e1c76950024270ba74b121f","https://git.kernel.org/stable/c/f42ba916689f5c7b1642092266d2f53cf527aaaa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27073 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme comment refers to such deallocations. | ["https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63","https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb","https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0","https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c","https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06","https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b","https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016","https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837","https://git.kernel.org/stable/c/1597cd1a88cfcdc4bf8b1b44cd458fed9a5a5d63","https://git.kernel.org/stable/c/24e51d6eb578b82ff292927f14b9f5ec05a46beb","https://git.kernel.org/stable/c/55ca0c7eae8499bb96f4e5d9b26af95e89c4e6a0","https://git.kernel.org/stable/c/656b8cc123d7635dd399d9f02594f27aa797ac3c","https://git.kernel.org/stable/c/7393c681f9aa05ffe2385e8716989565eed2fe06","https://git.kernel.org/stable/c/910363473e4bf97da3c350e08d915546dd6cc30b","https://git.kernel.org/stable/c/af37aed04997e644f7e1b52b696b62dcae3cc016","https://git.kernel.org/stable/c/d0b07f712bf61e1a3cf23c87c663791c42e50837","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27076 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: imx: csc/scaler: fix v4l2_ctrl_handler memory leak Free the memory allocated in v4l2_ctrl_handler_init on release. | ["https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce","https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01","https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684","https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e","https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282","https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328","https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b","https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f","https://git.kernel.org/stable/c/42492b00156c03a79fd4851190aa63045d6a15ce","https://git.kernel.org/stable/c/4797a3dd46f220e6d83daf54d70c5b33db6deb01","https://git.kernel.org/stable/c/5d9fe604bf9b5b09d2215225df55f22a4cbbc684","https://git.kernel.org/stable/c/6c92224721a439d6350db5933a1060768dcd565e","https://git.kernel.org/stable/c/8c2e4efe1278cd2b230cdbf90a6cefbf00acc282","https://git.kernel.org/stable/c/8df9a3c7044b847e9c4dc7e683fd64c6b873f328","https://git.kernel.org/stable/c/b1d0eebaf87cc9ccd05f779ec4a0589f95d6c18b","https://git.kernel.org/stable/c/d164ddc21e986dd9ad614b4b01746e5457aeb24f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet syzbot reported the following uninit-value access issue [1][2]: nci_rx_work() parses and processes received packet. When the payload length is zero, each message type handler reads uninitialized payload and KMSAN detects this issue. The receipt of a packet with a zero-size payload is considered unexpected, and therefore, such packets should be silently discarded. This patch resolved this issue by checking payload size before calling each message type handler codes. | ["https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff","https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240","https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c","https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a","https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a","https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16","https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7","https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f","https://git.kernel.org/stable/c/03fe259649a551d336a7f20919b641ea100e3fff","https://git.kernel.org/stable/c/11387b2effbb55f58dc2111ef4b4b896f2756240","https://git.kernel.org/stable/c/755e53bbc61bc1aff90eafa64c8c2464fd3dfa3c","https://git.kernel.org/stable/c/8948e30de81faee87eeee01ef42a1f6008f5a83a","https://git.kernel.org/stable/c/a946ebee45b09294c8b0b0e77410b763c4d2817a","https://git.kernel.org/stable/c/ac68d9fa09e410fa3ed20fb721d56aa558695e16","https://git.kernel.org/stable/c/b51ec7fc9f877ef869c01d3ea6f18f6a64e831a7","https://git.kernel.org/stable/c/d24b03535e5eb82e025219c2f632b485409c898f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35922 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbmon: prevent division by zero in fb_videomode_from_videomode() The expression htotal * vtotal can have a zero value on overflow. It is necessary to prevent division by zero like in fb_var_to_videomode(). Found by Linux Verification Center (linuxtesting.org) with Svace. | ["https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4","https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f","https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33","https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029","https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971","https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270","https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0","https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126","https://git.kernel.org/stable/c/1b107d637fed68a787da77a3514ad06e57abd0b4","https://git.kernel.org/stable/c/1fb52bc1de55e9e0bdf71fe078efd4da0889710f","https://git.kernel.org/stable/c/3d4b909704bf2114f64f87363fa22b5ef8ac4a33","https://git.kernel.org/stable/c/48d6bcfc31751ca2e753d901a2d82f27edf8a029","https://git.kernel.org/stable/c/664206ff8b019bcd1e55b10b2eea3add8761b971","https://git.kernel.org/stable/c/72d091b7515e0532ee015e144c906f3bcfdd6270","https://git.kernel.org/stable/c/951838fee462aa01fa2a6a91d56f9a495082e7f0","https://git.kernel.org/stable/c/c2d953276b8b27459baed1277a4fdd5dd9bd4126","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35925 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: prevent division by zero in blk_rq_stat_sum() The expression dst->nr_samples + src->nr_samples may have zero value on overflow. It is necessary to add a check to avoid division by zero. Found by Linux Verification Center (linuxtesting.org) with Svace. | ["https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8","https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854","https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe","https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7","https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02","https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68","https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c","https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14","https://git.kernel.org/stable/c/21e7d72d0cfcbae6042d498ea2e6f395311767f8","https://git.kernel.org/stable/c/512a01da7134bac8f8b373506011e8aaa3283854","https://git.kernel.org/stable/c/5f7fd6aa4c4877d77133ea86c14cf256f390b2fe","https://git.kernel.org/stable/c/6a55dab4ac956deb23690eedd74e70b892a378e7","https://git.kernel.org/stable/c/93f52fbeaf4b676b21acfe42a5152620e6770d02","https://git.kernel.org/stable/c/98ddf2604ade2d954bf5ec193600d5274a43fd68","https://git.kernel.org/stable/c/b0cb5564c3e8e0ee0a2d28c86fa7f02e82d64c3c","https://git.kernel.org/stable/c/edd073c78d2bf48c5b8bf435bbc3d61d6e7c6c14","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35930 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc() The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked. Check return value after calling lpfc_sli4_resume_rpi() and conditionally release the elsiocb resource. | ["https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf","https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b","https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f","https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7","https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a","https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8","https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8","https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f","https://git.kernel.org/stable/c/07a2aa674fca679316b8ac51440adb895b53a7cf","https://git.kernel.org/stable/c/2ae917d4bcab80ab304b774d492e2fcd6c52c06b","https://git.kernel.org/stable/c/3320126ed3afbc11934502319b340f91a4d61c8f","https://git.kernel.org/stable/c/7849e6f8410da96384e3d1f6b6d730f095142dc7","https://git.kernel.org/stable/c/c473288f27d15014447de5a891bdf22a0695847a","https://git.kernel.org/stable/c/e2cd32435b1dff3d63759476a3abc878e02fb6c8","https://git.kernel.org/stable/c/edf82aa7e9eb864a09229392054d131b34a5c9e8","https://git.kernel.org/stable/c/ee0b5f96b6d66a1e6698228dcb41df11ec7f352f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35933 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: Fix null ptr deref in btintel_read_version If hci_cmd_sync_complete() is triggered and skb is NULL, then hdev->req_skb is NULL, which will cause this issue. | ["https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28","https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e","https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b","https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9","https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912","https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645","https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990","https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b","https://git.kernel.org/stable/c/006936ecb4edfc3102464044f75858c714e34d28","https://git.kernel.org/stable/c/22d3053ef05f0b5045e45bd91e7473846261d65e","https://git.kernel.org/stable/c/68a69bb2ecafaacdb998a87783068fb51736f43b","https://git.kernel.org/stable/c/86e9b47e8a75c74b1bd83a479979b425c5dc8bd9","https://git.kernel.org/stable/c/b19fe5eea619d54eea59bb8a37c0f8d00ef0e912","https://git.kernel.org/stable/c/b79e040910101b020931ba0c9a6b77e81ab7f645","https://git.kernel.org/stable/c/ec2049fb2b8be3e108fe2ef1f1040f91e72c9990","https://git.kernel.org/stable/c/ffdca0a62abaf8c41d8d9ea132000fd808de329b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it still means hlist_for_each_entry_rcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane. In particular, the reference count can be zero. This can happen if ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry from inet6_addr_lst (hlist_del_init_rcu(&ifp->addr_lst)) and drops all references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough timing, this can happen: 1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry. 2. Then, the whole ipv6_del_addr is executed for the given entry. The reference count drops to zero and kfree_rcu is scheduled. 3. ipv6_get_ifaddr continues and tries to increments the reference count (in6_ifa_hold). 4. The rcu is unlocked and the entry is freed. 5. The freed entry is returned. Prevent increasing of the reference count in such case. The name in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe. [ 41.506330] refcount_t: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? __warn+0x7b/0x120 [ 41.517535] ? refcount_warn_saturate+0xa5/0x130 [ 41.517923] ? report_bug+0x164/0x190 [ 41.518240] ? handle_bug+0x3d/0x70 [ 41.518541] ? exc_invalid_op+0x17/0x70 [ 41.520972] ? asm_exc_invalid_op+0x1a/0x20 [ 41.521325] ? refcount_warn_saturate+0xa5/0x130 [ 41.521708] ipv6_get_ifaddr+0xda/0xe0 [ 41.522035] inet6_rtm_getaddr+0x342/0x3f0 [ 41.522376] ? __pfx_inet6_rtm_getaddr+0x10/0x10 [ 41.522758] rtnetlink_rcv_msg+0x334/0x3d0 [ 41.523102] ? netlink_unicast+0x30f/0x390 [ 41.523445] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 41.523832] netlink_rcv_skb+0x53/0x100 [ 41.524157] netlink_unicast+0x23b/0x390 [ 41.524484] netlink_sendmsg+0x1f2/0x440 [ 41.524826] __sys_sendto+0x1d8/0x1f0 [ 41.525145] __x64_sys_sendto+0x1f/0x30 [ 41.525467] do_syscall_64+0xa5/0x1b0 [ 41.525794] entry_SYSCALL_64_after_hwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated--- | ["https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652","https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70","https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb","https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83","https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129","https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1","https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903","https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb","https://git.kernel.org/stable/c/01b11a0566670612bd464a932e5ac2eae53d8652","https://git.kernel.org/stable/c/3fb02ec57ead2891a2306af8c51a306bc5945e70","https://git.kernel.org/stable/c/4b19e9507c275de0cfe61c24db69179dc52cf9fb","https://git.kernel.org/stable/c/6cdb20c342cd0193d3e956e3d83981d0f438bb83","https://git.kernel.org/stable/c/7633c4da919ad51164acbf1aa322cc1a3ead6129","https://git.kernel.org/stable/c/b4b3b69a19016d4e7fbdbd1dbcc184915eb862e1","https://git.kernel.org/stable/c/cca606e14264098cba65efa82790825dbf69e903","https://git.kernel.org/stable/c/de76ae9ea1a6cf9e77fcec4f2df2904e26c23ceb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35984 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: smbus: fix NULL function pointer dereference Baruch reported an OOPS when using the designware controller as target only. Target-only modes break the assumption of one transfer function always being available. Fix this by always checking the pointer in __i2c_transfer. [wsa: dropped the simplification in core-smbus to avoid theoretical regressions] | ["https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83","https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d","https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde","https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620","https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec","https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f","https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23","https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85","https://git.kernel.org/stable/c/357c64ef1ef39b1e7cd91ab6bdd304d043702c83","https://git.kernel.org/stable/c/40f1d79f07b49c8a64a861706e5163f2db4bd95d","https://git.kernel.org/stable/c/4e75e222d397c6752b229ed72fc4644c8c36ecde","https://git.kernel.org/stable/c/5a09eae9a7db597fe0c1fc91636205b4a25d2620","https://git.kernel.org/stable/c/5fd72404587d7db4acb2d241fd8c387afb0a7aec","https://git.kernel.org/stable/c/91811a31b68d3765b3065f4bb6d7d6d84a7cfc9f","https://git.kernel.org/stable/c/ad3c3ac7a03be3697114f781193dd3e9d97e6e23","https://git.kernel.org/stable/c/e3425674ff68dc521c57c6eabad0cbd20a027d85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46707 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3 On a system with a GICv3, if a guest hasn't been configured with GICv3 and that the host is not capable of GICv2 emulation, a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2. We therefore try to emulate the SGI access, only to hit a NULL pointer as no private interrupt is allocated (no GIC, remember?). The obvious fix is to give the guest what it deserves, in the shape of a UNDEF exception. | ["https://git.kernel.org/stable/c/15818af2f7aa55eff375333cb7689df15d3f24ef","https://git.kernel.org/stable/c/2073132f6ed3079369e857a8deb33d11bdd983bc","https://git.kernel.org/stable/c/3e6245ebe7ef341639e9a7e402b3ade8ad45a19f","https://git.kernel.org/stable/c/94d4fbad01b19ec5eab3d6b50aaec4f9db8b2d8d","https://git.kernel.org/stable/c/96b076e8ee5bc3a1126848c8add0f74bd30dc9d1","https://git.kernel.org/stable/c/9d7629bec5c3f80bd0e3bf8103c06a2f7046bd92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49994 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed | ["https://git.kernel.org/stable/c/0842ddd83939eb4db940b9af7d39e79722bc41aa","https://git.kernel.org/stable/c/697ba0b6ec4ae04afb67d3911799b5e2043b4455","https://git.kernel.org/stable/c/6c9915fa9410cbb9bd75ee283c03120046c56d3d","https://git.kernel.org/stable/c/8476f8428e8b48fd7a0e4258fa2a96a8f4468239","https://git.kernel.org/stable/c/a99bacb35c1416355eef957560e8fcac3a665549"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50014 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat. | ["https://git.kernel.org/stable/c/13ea9547763a0488a90ff37cdf52ec85e36ea344","https://git.kernel.org/stable/c/23dfdb56581ad92a9967bcd720c8c23356af74c1","https://git.kernel.org/stable/c/6e35f560daebe40264c95e9a1ab03110d4997df6","https://git.kernel.org/stable/c/b002031d585a14eed511117dda8c6452a804d508","https://git.kernel.org/stable/c/d157fc20ca5239fd56965a5a8aa1a0e25919891a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44955 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Don't refer to dc_sink in is_dsc_need_re_compute [Why] When unplug one of monitors connected after mst hub, encounter null pointer dereference. It's due to dc_sink get released immediately in early_unregister() or detect_ctx(). When commit new state which directly referring to info stored in dc_sink will cause null pointer dereference. [how] Remove redundant checking condition. Relevant condition should already be covered by checking if dsc_aux is null or not. Also reset dsc_aux to NULL when the connector is disconnected. | ["https://git.kernel.org/stable/c/39b217193729aa45eded8de24d9245468a0c0263","https://git.kernel.org/stable/c/c7e65cab54a89f4df54110f0b44c4ade93d1a911","https://git.kernel.org/stable/c/fcf6a49d79923a234844b8efe830a61f3f0584e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48879 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. | ["https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a28399cb5","https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794","https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452","https://git.kernel.org/stable/c/703c13fe3c9af557d312f5895ed6a5fda2711104","https://git.kernel.org/stable/c/adc96d30f6503d30dc68670c013716f1d9fcc747","https://git.kernel.org/stable/c/e2ea55564229e4bea1474af15b111b3a3043b76f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48905 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: free reset-work-item when flushing Fix a tiny memory leak when flushing the reset work queue. | ["https://git.kernel.org/stable/c/39738a2346b270e8f72f88d8856de2c167bd2899","https://git.kernel.org/stable/c/4c26745e4576cec224092e6cc12e37829333b183","https://git.kernel.org/stable/c/58b07100c20e95c78b8cb4d6d28ca53eb9ef81f2","https://git.kernel.org/stable/c/6acbc8875282d3ca8a73fa93cd7a9b166de5019c","https://git.kernel.org/stable/c/786576c03b313a9ff6585458aa0dfd039d897f51","https://git.kernel.org/stable/c/8d0657f39f487d904fca713e0bc39c2707382553"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48908 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe() During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pci_id_table' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices. The following log reveals it: [ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pci_probe+0x18d/0x13e0 [com20020_pci] [ 3.975181] Call Trace: [ 3.976208] local_pci_probe+0x13f/0x210 [ 3.977248] pci_device_probe+0x34c/0x6d0 [ 3.977255] ? pci_uevent+0x470/0x470 [ 3.978265] really_probe+0x24c/0x8d0 [ 3.978273] __driver_probe_device+0x1b3/0x280 [ 3.979288] driver_probe_device+0x50/0x370 Fix this by checking whether the 'ci' is a null pointer first. | ["https://git.kernel.org/stable/c/5f394102ee27dbf051a4e283390cd8d1759dacea","https://git.kernel.org/stable/c/8e3bc7c5bbf87e86e9cd652ca2a9166942d86206","https://git.kernel.org/stable/c/b1ee6b9340a38bdb9e5c90f0eac5b22b122c3049","https://git.kernel.org/stable/c/b838add93e1dd98210482dc433768daaf752bdef","https://git.kernel.org/stable/c/bd6f1fd5d33dfe5d1b4f2502d3694a7cc13f166d","https://git.kernel.org/stable/c/ca0bdff4249a644f2ca7a49d410d95b8dacf1f72","https://git.kernel.org/stable/c/e50c589678e50f8d574612e473ca60ef45190896","https://git.kernel.org/stable/c/ea372aab54903310756217d81610901a8e66cb7d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48910 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ipv6: ensure we call ipv6_mc_down() at most once There are two reasons for addrconf_notify() to be called with NETDEV_DOWN: either the network device is actually going down, or IPv6 was disabled on the interface. If either of them stays down while the other is toggled, we repeatedly call the code for NETDEV_DOWN, including ipv6_mc_down(), while never calling the corresponding ipv6_mc_up() in between. This will cause a new entry in idev->mc_tomb to be allocated for each multicast group the interface is subscribed to, which in turn leaks one struct ifmcaddr6 per nontrivial multicast group the interface is subscribed to. The following reproducer will leak at least $n objects: ip addr add ff2e::4242/32 dev eth0 autojoin sysctl -w net.ipv6.conf.eth0.disable_ipv6=1 for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0 done Joining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting the sysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2) can also be used to create a nontrivial idev->mc_list, which will the leak objects with the right up-down-sequence. Based on both sources for NETDEV_DOWN events the interface IPv6 state should be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for it The functions ipv6_mc_up() and ipv6_down() should only be run when this state changes. Implement this by remembering when the IPv6 state is ready, and only run ipv6_mc_down() if it actually changed from ready to not ready. The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything | ["https://git.kernel.org/stable/c/24888915364cfa410de62d8abb5df95c3b67455d","https://git.kernel.org/stable/c/72124e65a70b84e6303a5cd21b0ac1f27d7d61a4","https://git.kernel.org/stable/c/9588ac2eddc2f223ebcebf6e9f5caed84d32922b","https://git.kernel.org/stable/c/9995b408f17ff8c7f11bc725c8aa225ba3a63b1c","https://git.kernel.org/stable/c/9a8736b2da28b24f01707f592ff059b9f90a058c","https://git.kernel.org/stable/c/b11781515208dd31fbcd0b664078dce5dc44523f","https://git.kernel.org/stable/c/c71bf3229f9e9dd60ba02f5a5be02066edf57012","https://git.kernel.org/stable/c/f4c63b24dea9cc2043ff845dcca9aaf8109ea38a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48911 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: fix possible use-after-free Eric Dumazet says: The sock_hold() side seems suspect, because there is no guarantee that sk_refcnt is not already 0. On failure, we cannot queue the packet and need to indicate an error. The packet will be dropped by the caller. v2: split skb prefetch hunk into separate change | ["https://git.kernel.org/stable/c/21b27b2baa27423286e9b8d3f0b194d587083d95","https://git.kernel.org/stable/c/34dc4a6a7f261736ef7183868a5bddad31c7f9e3","https://git.kernel.org/stable/c/43c25da41e3091b31a906651a43e80a2719aa1ff","https://git.kernel.org/stable/c/4d05239203fa38ea8a6f31e228460da4cb17a71a","https://git.kernel.org/stable/c/c3873070247d9e3c7a6b0cf9bf9b45e8018427b1","https://git.kernel.org/stable/c/dcc3cb920bf7ba66ac5e9272293a9ba5f80917ee","https://git.kernel.org/stable/c/dd648bd1b33a828f62befa696b206c688da0ec43","https://git.kernel.org/stable/c/ef97921ccdc243170fcef857ba2a17cf697aece5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. | ["https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a","https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393","https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8","https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd","https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2","https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b","https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Check endpoint is valid before dereferencing it When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint. Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it. [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8 [233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270 [233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198 | ["https://git.kernel.org/stable/c/08864dc14a6803f0377ca77b9740b26db30c020f","https://git.kernel.org/stable/c/2d2820d5f375563690c96e60676855205abfb7f5","https://git.kernel.org/stable/c/375be2dd61a072f7b1cac9b17eea59e07b58db3a","https://git.kernel.org/stable/c/66fc1600855c05c4ba4e997184c91cf298e0405c","https://git.kernel.org/stable/c/9891e5c73cab3fd9ed532dc50e9799e55e974766","https://git.kernel.org/stable/c/e8fb5bc76eb86437ab87002d4a36d6da02165654","https://git.kernel.org/stable/c/f39c813af0b64f44af94e435c07bfa1ddc2575f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52907 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame() Fix a use-after-free that occurs in hcd when in_urb sent from pn533_usb_send_frame() is completed earlier than out_urb. Its callback frees the skb data in pn533_send_async_complete() that is used as a transfer buffer of out_urb. Wait before sending in_urb until the callback of out_urb is called. To modify the callback of out_urb alone, separate the complete function of out_urb and ack_urb. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in dummy_timer Call Trace: memcpy (mm/kasan/shadow.c:65) dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352) transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453) dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972) arch_static_branch (arch/x86/include/asm/jump_label.h:27) static_key_false (include/linux/jump_label.h:207) timer_expire_exit (include/trace/events/timer.h:127) call_timer_fn (kernel/time/timer.c:1475) expire_timers (kernel/time/timer.c:1519) __run_timers (kernel/time/timer.c:1790) run_timer_softirq (kernel/time/timer.c:1803) | ["https://git.kernel.org/stable/c/0ca78c99656f5c448567db1e148367aa3b01c80a","https://git.kernel.org/stable/c/321db5131c92983dac4f3338e8fbb6df214238c0","https://git.kernel.org/stable/c/35529d6b827eedb6bf7e81130e4b7e0aba9e58d2","https://git.kernel.org/stable/c/39ae73e581112cfe27ba50aecb1c891ce57cecb1","https://git.kernel.org/stable/c/8998db5021a28ad67aa8d627bdb4226e4046ccc4","https://git.kernel.org/stable/c/9424d2205fe94a095fb9365ec0c6137f0b394a2b","https://git.kernel.org/stable/c/9dab880d675b9d0dd56c6428e4e8352a3339371d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52827 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats() len is extracted from HTT message and could be an unexpected value in case errors happen, so add validation before using to avoid possible out-of-bound read in the following message iteration and parsing. The same issue also applies to ppdu_info->ppdu_stats.common.num_users, so validate it before using too. These are found during code review. Compile test only. | ["https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e","https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57","https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c","https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e","https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57","https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50268 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The "*cmd" variable can be controlled by the user via debugfs. That means "new_cam" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control() | ["https://git.kernel.org/stable/c/3a2ba841659a0f15102585120dea75d8d5209616","https://git.kernel.org/stable/c/604314ecd682913925980dc955caea2d036eab5f","https://git.kernel.org/stable/c/69e19774f15e12dda6c6c58001d059e30895009b","https://git.kernel.org/stable/c/7dd08a0b4193087976db6b3ee7807de7e8316f96","https://git.kernel.org/stable/c/8f47984b35f3be0cfc652c2ca358d5768ea3456b","https://git.kernel.org/stable/c/d76923164705821aa1b01b8d9d1741f20c654ab4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4622 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's af_unix component can be exploited to achieve local privilege escalation. The unix_stream_sendpage() function tries to add data to the last skb in the peer's recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free. We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c. | ["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y\u0026id=790c2f9d15b594350ae9bca7b236f2b1859de02c","https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y\u0026id=790c2f9d15b594350ae9bca7b236f2b1859de02c","https://kernel.dance/790c2f9d15b594350ae9bca7b236f2b1859de02c","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56614 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xsk: fix OOB map writes when deleting elements Jordy says: " In the xsk_map_delete_elem function an unsigned integer (map->max_entries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL; This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock); The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead to further memory corruption. " It indeed results in following splat: [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: error_code(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? __die+0x20/0x60 [76613.051581] ? page_fault_oops+0x15a/0x450 [76613.055747] ? search_extable+0x22/0x30 [76613.059649] ? search_bpf_extables+0x5f/0x80 [76613.063988] ? exc_page_fault+0xa9/0x140 [76613.067975] ? asm_exc_page_fault+0x22/0x30 [76613.072229] ? xsk_map_delete_elem+0x2d/0x60 [76613.076573] ? xsk_map_delete_elem+0x23/0x60 [76613.080914] __sys_bpf+0x19b7/0x23c0 [76613.084555] __x64_sys_bpf+0x1a/0x20 [76613.088194] do_syscall_64+0x37/0xb0 [76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated--- | ["https://git.kernel.org/stable/c/32cd3db7de97c0c7a018756ce66244342fd583f0","https://git.kernel.org/stable/c/4d03f705e9d7aabebc6bfa5810f8aab6d176cbb7","https://git.kernel.org/stable/c/d486b5741d987d3e0e6be4ac22cafdf94e6d1a47","https://git.kernel.org/stable/c/ed08c93d5a9801cc8f224a046411fd603c538d07","https://git.kernel.org/stable/c/f8abd03f83d5fe81e76eb93e2c4373eb9f75fd8a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53103 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL. | ["https://git.kernel.org/stable/c/285266ef92f7b4bf7d26e1e95e215ce6a6badb4a","https://git.kernel.org/stable/c/414476c4fb11be070c09ab8f3e75c9ee324a108a","https://git.kernel.org/stable/c/4bdc5a62c6e50600d8a1c3e18fd6dce0c27c9497","https://git.kernel.org/stable/c/4fe1d42f2acc463b733bb42e3f8e67dbc2a0eb2d","https://git.kernel.org/stable/c/7cf25987820350cb950856c71b409e5b6eed52bd","https://git.kernel.org/stable/c/8621725afb38e111969c64280b71480afde2aace","https://git.kernel.org/stable/c/98d8dde9232250a57ad5ef16479bf6a349e09b80","https://git.kernel.org/stable/c/e0fe3392371293175f25028020ded5267f4cd8e3","https://git.kernel.org/stable/c/e629295bd60abf4da1db85b82819ca6a4f6c1e79"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56608 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' An issue was identified in the dcn21_link_encoder_create function where an out-of-bounds access could occur when the hpd_source index was used to reference the link_enc_hpd_regs array. This array has a fixed size and the index was not being checked against the array's bounds before accessing it. This fix adds a conditional check to ensure that the hpd_source index is within the valid range of the link_enc_hpd_regs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior. References: [ 65.920507] ------------[ cut here ]------------ [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [ 65.920519] index 7 is out of range for type 'dcn10_link_enc_hpd_registers [5]' [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020 [ 65.920527] Call Trace: [ 65.920529] <TASK> [ 65.920532] dump_stack_lvl+0x48/0x70 [ 65.920541] dump_stack+0x10/0x20 [ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0 [ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [ 65.921009] link_create+0x6d3/0xed0 [amdgpu] [ 65.921355] create_links+0x18a/0x4e0 [amdgpu] [ 65.921679] dc_create+0x360/0x720 [amdgpu] [ 65.921999] ? dmi_matches+0xa0/0x220 [ 65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [ 65.922342] ? console_unlock+0x77/0x120 [ 65.922348] ? dev_printk_emit+0x86/0xb0 [ 65.922354] dm_hw_init+0x15/0x40 [amdgpu] [ 65.922686] amdgpu_device_init+0x26a8/0x33a0 [amdgpu] [ 65.922921] amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu] [ 65.923087] amdgpu_pci_probe+0x1b7/0x630 [amdgpu] [ 65.923087] local_pci_probe+0x4b/0xb0 [ 65.923087] pci_device_probe+0xc8/0x280 [ 65.923087] really_probe+0x187/0x300 [ 65.923087] __driver_probe_device+0x85/0x130 [ 65.923087] driver_probe_device+0x24/0x110 [ 65.923087] __driver_attach+0xac/0x1d0 [ 65.923087] ? __pfx___driver_attach+0x10/0x10 [ 65.923087] bus_for_each_dev+0x7d/0xd0 [ 65.923087] driver_attach+0x1e/0x30 [ 65.923087] bus_add_driver+0xf2/0x200 [ 65.923087] driver_register+0x64/0x130 [ 65.923087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu] [ 65.923087] __pci_register_driver+0x61/0x70 [ 65.923087] amdgpu_init+0x7d/0xff0 [amdgpu] [ 65.923087] do_one_initcall+0x49/0x310 [ 65.923087] ? kmalloc_trace+0x136/0x360 [ 65.923087] do_init_module+0x6a/0x270 [ 65.923087] load_module+0x1fce/0x23a0 [ 65.923087] init_module_from_file+0x9c/0xe0 [ 65.923087] ? init_module_from_file+0x9c/0xe0 [ 65.923087] idempotent_init_module+0x179/0x230 [ 65.923087] __x64_sys_finit_module+0x5d/0xa0 [ 65.923087] do_syscall_64+0x76/0x120 [ 65.923087] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 65.923087] RIP: 0033:0x7f2d80f1e88d [ 65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002 [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480 [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0 [ 65.923087] </TASK> [ 65.923927] ---[ end trace ]--- | ["https://git.kernel.org/stable/c/08ac5fdb9c6dc34d0ed4bc64ce3c5c3d411b3b53","https://git.kernel.org/stable/c/280f722601c8bf4d8a9c62dd727cf3a2fd0a47be","https://git.kernel.org/stable/c/5bd410c21037107b83ffbb51dd2d6460f9de9ed1","https://git.kernel.org/stable/c/63de35a8fcfca59ae8750d469a7eb220c7557baf","https://git.kernel.org/stable/c/b19ca8425a4b86e8f0d7c33c4e87ef7b0ebdaa29","https://git.kernel.org/stable/c/f01ddd589e162979421e6914b1c74018633f01e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38552 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential index out of bounds in color transformation function Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max | ["https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7","https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123","https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86","https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c","https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca","https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29","https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869","https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e","https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d","https://git.kernel.org/stable/c/04bc4d1090c343025d69149ca669a27c5b9c34a7","https://git.kernel.org/stable/c/123edbae64f4d21984359b99c6e79fcde31c6123","https://git.kernel.org/stable/c/4e8c8b37ee84b3b19c448d2b8e4c916d2f5b9c86","https://git.kernel.org/stable/c/604c506ca43fce52bb882cff9c1fdf2ec3b4029c","https://git.kernel.org/stable/c/63ae548f1054a0b71678d0349c7dc9628ddd42ca","https://git.kernel.org/stable/c/7226ddf3311c5e5a7726ad7d4e7b079bb3cfbb29","https://git.kernel.org/stable/c/98b8a6bfd30d07a19cfacdf82b50f84bf3360869","https://git.kernel.org/stable/c/ced9c4e2289a786b8fa684d8893b7045ea53ef7e","https://git.kernel.org/stable/c/e280ab978c81443103d7c61bdd1d8d708cf6ed6d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50246 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check | ["https://git.kernel.org/stable/c/2fcae4c2014a40c8ae0fc3d8cca3ba9e168308de","https://git.kernel.org/stable/c/c4a8ba334262e9a5c158d618a4820e1b9c12495c","https://git.kernel.org/stable/c/e91fbb21f248bdd8140f343dac32b77b9bc10fec","https://git.kernel.org/stable/c/effac690913af9a6c3d6cd967281a34e47ed3e4c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49931 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/a4aef827a41cdaf6201bbaf773c1eae4e20e967b","https://git.kernel.org/stable/c/ad791e3ec60cb66c1e4dc121ffbf872df312427d","https://git.kernel.org/stable/c/d0e4274d9dc9f8409d56d622cd3ecf7b6fd49e2f","https://git.kernel.org/stable/c/e106b7ad13c1d246adaa57df73edb8f8b8acb240"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46744 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Squashfs: sanity check symbolic link size Syzkiller reports a "KMSAN: uninit-value in pick_link" bug. This is caused by an uninitialised page, which is ultimately caused by a corrupted symbolic link size read from disk. The reason why the corrupted symlink size causes an uninitialised page is due to the following sequence of events: 1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size. 2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number. 3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page. This patch adds a sanity check which checks that the symbolic link size is not larger than expected. -- V2: fix spelling mistake. | ["https://git.kernel.org/stable/c/087f25b2d36adae19951114ffcbb7106ed405ebb","https://git.kernel.org/stable/c/1b9451ba6f21478a75288ea3e3fca4be35e2a438","https://git.kernel.org/stable/c/5c8906de98d0d7ad42ff3edf2cb6cd7e0ea658c4","https://git.kernel.org/stable/c/810ee43d9cd245d138a2733d87a24858a23f577d","https://git.kernel.org/stable/c/c3af7e460a526007e4bed1ce3623274a1a6afe5e","https://git.kernel.org/stable/c/ef4e249971eb77ec33d74c5c3de1e2576faf6c90","https://git.kernel.org/stable/c/f82cb7f24032ed023fc67d26ea9bf322d8431a90","https://git.kernel.org/stable/c/fac5e82ab1334fc8ed6ff7183702df634bd1d93d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26592 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix UAF issue in ksmbd_tcp_new_connection() The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on `struct tcp_transport` in ksmbd_tcp_new_connection() function. | ["https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111","https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1","https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544","https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126","https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6","https://git.kernel.org/stable/c/24290ba94cd0136e417283b0dbf8fcdabcf62111","https://git.kernel.org/stable/c/380965e48e9c32ee4263c023e1d830ea7e462ed1","https://git.kernel.org/stable/c/38d20c62903d669693a1869aa68c4dd5674e2544","https://git.kernel.org/stable/c/69d54650b751532d1e1613a4fb433e591aeef126","https://git.kernel.org/stable/c/999daf367b924fdf14e9d83e034ee0f86bc17ec6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42284 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: Return non-zero value from tipc_udp_addr2str() on error tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address. | ["https://git.kernel.org/stable/c/253405541be2f15ffebdeac2f4cf4b7e9144d12f","https://git.kernel.org/stable/c/2abe350db1aa599eeebc6892237d0bce0f1de62a","https://git.kernel.org/stable/c/5eea127675450583680c8170358bcba43227bd69","https://git.kernel.org/stable/c/728734352743a78b4c5a7285b282127696a4a813","https://git.kernel.org/stable/c/76ddf84a52f0d8ec3f5db6ccce08faf202a17d28","https://git.kernel.org/stable/c/7ec3335dd89c8d169e9650e4bac64fde71fdf15b","https://git.kernel.org/stable/c/aa38bf74899de07cf70b50cd17f8ad45fb6654c8","https://git.kernel.org/stable/c/fa96c6baef1b5385e2f0c0677b32b3839e716076"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-6559 | Low | N/A | The Linux kernel, as used in Ubuntu 18.04 LTS and Ubuntu 18.10, allows local users to obtain names of files in which they would not normally be able to access via an overlayfs mount inside of a user namespace. | ["http://www.securityfocus.com/bid/105752","https://launchpad.net/bugs/1793458","https://lists.ubuntu.com/archives/kernel-team/2018-October/096172.html","https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-6559.html","https://usn.ubuntu.com/3832-1/","https://usn.ubuntu.com/3833-1/","https://usn.ubuntu.com/3835-1/","https://usn.ubuntu.com/3836-1/","https://usn.ubuntu.com/3836-2/","http://www.securityfocus.com/bid/105752","https://launchpad.net/bugs/1793458","https://lists.ubuntu.com/archives/kernel-team/2018-October/096172.html","https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-6559.html","https://usn.ubuntu.com/3832-1/","https://usn.ubuntu.com/3833-1/","https://usn.ubuntu.com/3835-1/","https://usn.ubuntu.com/3836-1/","https://usn.ubuntu.com/3836-2/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42075 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix remap of arena. The bpf arena logic didn't account for mremap operation. Add a refcnt for multiple mmap events to prevent use-after-free in arena_vm_close. | ["https://git.kernel.org/stable/c/87496a1b01e8e2e399428c0db25e106f7961d01e","https://git.kernel.org/stable/c/b90d77e5fd784ada62ddd714d15ee2400c28e1cf","https://git.kernel.org/stable/c/87496a1b01e8e2e399428c0db25e106f7961d01e","https://git.kernel.org/stable/c/b90d77e5fd784ada62ddd714d15ee2400c28e1cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42269 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init(). ip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id], but the function is exposed to user space before the entry is allocated via register_pernet_subsys(). Let's call register_pernet_subsys() before xt_register_template(). | ["https://git.kernel.org/stable/c/419ee6274c5153b89c4393c1946faa4c3cad4f9e","https://git.kernel.org/stable/c/87dba44e9471b79b255d0736858a897332db9226","https://git.kernel.org/stable/c/91b6df6611b7edb28676c4f63f90c56c30d3e601","https://git.kernel.org/stable/c/c22921df777de5606f1047b1345b8d22ef1c0b34","https://git.kernel.org/stable/c/e85b9b6a87be4cb3710082038b677e97f2389003"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42270 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init(). We had a report that iptables-restore sometimes triggered null-ptr-deref at boot time. [0] The problem is that iptable_nat_table_init() is exposed to user space before the kernel fully initialises netns. In the small race window, a user could call iptable_nat_table_init() that accesses net_generic(net, iptable_nat_net_id), which is available only after registering iptable_nat_net_ops. Let's call register_pernet_subsys() before xt_register_template(). [0]: bpfilter: Loaded bpfilter_umh pid 11702 Started bpfilter BUG: kernel NULL pointer dereference, address: 0000000000000013 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 0 P4D 0 PREEMPT SMP NOPTI CPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1 Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat Code: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c RSP: 0018:ffffbef902843cd0 EFLAGS: 00010246 RAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80 RDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0 RBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240 R10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000 R13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004 FS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? xt_find_table_lock (net/netfilter/x_tables.c:1259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? page_fault_oops (arch/x86/mm/fault.c:727) ? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570) ? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat xt_find_table_lock (net/netfilter/x_tables.c:1259) xt_request_find_table_lock (net/netfilter/x_tables.c:1287) get_info (net/ipv4/netfilter/ip_tables.c:965) ? security_capable (security/security.c:809 (discriminator 13)) ? ns_capable (kernel/capability.c:376 kernel/capability.c:397) ? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656) ? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter nf_getsockopt (net/netfilter/nf_sockopt.c:116) ip_getsockopt (net/ipv4/ip_sockglue.c:1827) __sys_getsockopt (net/socket.c:2327) __x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) RIP: 0033:0x7f62844685ee Code: 48 8b 0d 45 28 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09 RSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0 R10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2 R13: 00007f6284 ---truncated--- | ["https://git.kernel.org/stable/c/08ed888b69a22647153fe2bec55b7cd0a46102cc","https://git.kernel.org/stable/c/5830aa863981d43560748aa93589c0695191d95d","https://git.kernel.org/stable/c/70014b73d7539fcbb6b4ff5f37368d7241d8e626","https://git.kernel.org/stable/c/95590a4929027769af35b153645c0ab6fd22b29b","https://git.kernel.org/stable/c/b98ddb65fa1674b0e6b52de8af9103b63f51b643"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44966 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix corruption when not offsetting data start Commit 04d82a6d0881 ("binfmt_flat: allow not offsetting data start") introduced a RISC-V specific variant of the FLAT format which does not allocate any space for the (obsolete) array of shared library pointers. However, it did not disable the code which initializes the array, resulting in the corruption of sizeof(long) bytes before the DATA segment, generally the end of the TEXT segment. Introduce MAX_SHARED_LIBS_UPDATE which depends on the state of CONFIG_BINFMT_FLAT_NO_DATA_START_OFFSET to guard the initialization of the shared library pointer region so that it will only be initialized if space is reserved for it. | ["https://git.kernel.org/stable/c/3a684499261d0f7ed5ee72793025c88c2276809c","https://git.kernel.org/stable/c/3eb3cd5992f7a0c37edc8d05b4c38c98758d8671","https://git.kernel.org/stable/c/49df34d2b7da9e57c839555a2f7877291ce45ad1","https://git.kernel.org/stable/c/9350ba06ee61db392c486716ac68ecc20e030f7c","https://git.kernel.org/stable/c/af65d5383854cc3f172a7d0843b628758bf462c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49567 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix uninit-value in mpol_rebind_policy() mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask when pol->mode is MPOL_LOCAL. Check pol->mode before access pol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c). BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline] BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae KMSAN: uninit-value in mpol_rebind_task (2) https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dc This patch seems to fix below bug too. KMSAN: uninit-value in mpol_rebind_mm (2) https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926b The uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy(). When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c `mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags` is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags; will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind() pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized, which will be accessed in mpol_rebind_policy(). | ["https://git.kernel.org/stable/c/018160ad314d75b1409129b2247b614a9f35894c","https://git.kernel.org/stable/c/13d51565cec1aa432a6ab363edc2bbc53c6f49cb","https://git.kernel.org/stable/c/5735845906fb1d90fe597f8b503fc0a857d475e3","https://git.kernel.org/stable/c/777e563f10e91e91130fe06bee85220d508e7b9b","https://git.kernel.org/stable/c/8c5429a04ccd8dbcc3c753dab2f4126774ec28d4","https://git.kernel.org/stable/c/a1f8765f68bc9bf5744b365bb9f5e0b6db93edfe","https://git.kernel.org/stable/c/aaa1c5d635a6fca2043513ffb5be169f9cd17d9e","https://git.kernel.org/stable/c/ddb3f0b68863bd1c5f43177eea476bce316d4993"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49657 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usbnet: fix memory leak in error case usbnet_write_cmd_async() mixed up which buffers need to be freed in which error case. v2: add Fixes tag v3: fix uninitialized buf pointer | ["https://git.kernel.org/stable/c/0085da9df3dced730027923a6b48f58e9016af91","https://git.kernel.org/stable/c/04894ab34faf40ab72a8a5ab5b404bb0606bbbff","https://git.kernel.org/stable/c/3eed421ca5c809da93456f69203d164d5220be3d","https://git.kernel.org/stable/c/5269209f54dd8dfd15f9383f3a3a1fe8370764f8","https://git.kernel.org/stable/c/b55a21b764c1e182014630fa5486d717484ac58f","https://git.kernel.org/stable/c/d5165e657987ff4ba0ace896d4376a3718a9fbc3","https://git.kernel.org/stable/c/db89582ff330556188da856e01382ccbf3a5e706","https://git.kernel.org/stable/c/e7b4f69946a38209b4a4f660bf0e4cbed94f9b4b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56599 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: avoid NULL pointer error during sdio remove When running 'rmmod ath10k', ath10k_sdio_remove() will free sdio workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON is set to yes, kernel panic will happen: Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2c This is because during 'rmmod ath10k', ath10k_sdio_remove() will call ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release() will finally be called in ath10k_core_destroy(). This function will free struct cfg80211_registered_device *rdev and all its members, including wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON. After device release, destroy_workqueue() will use NULL pointer then the kernel panic happen. Call trace: ath10k_sdio_remove ->ath10k_core_unregister …… ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free …… ->wiphy_dev_release ->destroy_workqueue Need to call destroy_workqueue() before ath10k_core_destroy(), free the work queue buffer first and then free pointer of work queue by ath10k_core_destroy(). This order matches the error path order in ath10k_sdio_probe(). No work will be queued on sdio workqueue between it is destroyed and ath10k_core_destroy() is called. Based on the call_stack above, the reason is: Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and ath10k_sdio_irq_disable() will queue work on sdio workqueue. Sleep timer will be deleted before ath10k_core_destroy() in ath10k_hif_power_down(). ath10k_sdio_irq_disable() only be called in ath10k_hif_stop(). ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif bus, so ath10k_sdio_hif_tx_sg() won't be called anymore. Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189 | ["https://git.kernel.org/stable/c/27d5d217ae7ffb99dd623375a17a7d3418d9c755","https://git.kernel.org/stable/c/27fda36eedad9e4ec795dc481f307901d1885112","https://git.kernel.org/stable/c/543c0924d446b21f35701ca084d7feca09511220","https://git.kernel.org/stable/c/6e5dbd1c04abf2c19b2282915e6fa48b6ccc6921","https://git.kernel.org/stable/c/95c38953cb1ecf40399a676a1f85dfe2b5780a9a","https://git.kernel.org/stable/c/b35de9e01fc79c7baac666fb2dcb4ba7698a1d97"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50146 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Don't call cleanup on profile rollback failure When profile rollback fails in mlx5e_netdev_change_profile, the netdev profile var is left set to NULL. Avoid a crash when unloading the driver by not calling profile->cleanup in such a case. This was encountered while testing, with the original trigger that the wq rescuer thread creation got interrupted (presumably due to Ctrl+C-ing modprobe), which gets converted to ENOMEM (-12) by mlx5e_priv_init, the profile rollback also fails for the same reason (signal still active) so the profile is left as NULL, leading to a crash later in _mlx5e_remove. [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode <snipped> [ 745.551290] Call Trace: [ 745.551590] <TASK> [ 745.551866] ? __die+0x20/0x60 [ 745.552218] ? page_fault_oops+0x150/0x400 [ 745.555307] ? exc_page_fault+0x79/0x240 [ 745.555729] ? asm_exc_page_fault+0x22/0x30 [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core] [ 745.556698] auxiliary_bus_remove+0x18/0x30 [ 745.557134] device_release_driver_internal+0x1df/0x240 [ 745.557654] bus_remove_device+0xd7/0x140 [ 745.558075] device_del+0x15b/0x3c0 [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core] [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core] [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core] [ 745.560694] pci_device_remove+0x39/0xa0 [ 745.561112] device_release_driver_internal+0x1df/0x240 [ 745.561631] driver_detach+0x47/0x90 [ 745.562022] bus_remove_driver+0x84/0x100 [ 745.562444] pci_unregister_driver+0x3b/0x90 [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core] [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0 [ 745.563886] ? kmem_cache_free+0x1b0/0x460 [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190 [ 745.564825] do_syscall_64+0x6d/0x140 [ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b | ["https://git.kernel.org/stable/c/3955b77494c3c7d14873b1db67e7e00c46a714db","https://git.kernel.org/stable/c/4dbc1d1a9f39c3711ad2a40addca04d07d9ab5d0","https://git.kernel.org/stable/c/d6fe973c8873c998734a050f366b28facc03d32a","https://git.kernel.org/stable/c/db84cb4c8c565e6d4de84b23c2818b63991adfdd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38557 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Reload only IB representors upon lag disable/enable On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded. In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock: Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180 Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above. While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design. | ["https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4","https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07","https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a","https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc","https://git.kernel.org/stable/c/0f06228d4a2dcc1fca5b3ddb0eefa09c05b102c4","https://git.kernel.org/stable/c/0f320f28f54b1b269a755be2e3fb3695e0b80b07","https://git.kernel.org/stable/c/e93fc8d959e56092e2eca1e5511c2d2f0ad6807a","https://git.kernel.org/stable/c/f03c714a0fdd1f93101a929d0e727c28a66383fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44939 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix null ptr deref in dtInsertEntry [syzbot reported] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713 ... [Analyze] In dtInsertEntry(), when the pointer h has the same value as p, after writing name in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause the previously true judgment "p->header.flag & BT-LEAF" to change to no after writing the name operation, this leads to entering an incorrect branch and accessing the uninitialized object ih when judging this condition for the second time. [Fix] After got the page, check freelist first, if freelist == 0 then exit dtInsert() and return -EINVAL. | ["https://git.kernel.org/stable/c/53023ab11836ac56fd75f7a71ec1356e50920fa9","https://git.kernel.org/stable/c/6ea10dbb1e6c58384136e9adfd75f81951e423f6","https://git.kernel.org/stable/c/9c2ac38530d1a3ee558834dfa16c85a40fd0e702","https://git.kernel.org/stable/c/ce6dede912f064a855acf6f04a04cbb2c25b8c8c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42073 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems The following two shared buffer operations make use of the Shared Buffer Status Register (SBSR): # devlink sb occupancy snapshot pci/0000:01:00.0 # devlink sb occupancy clearmax pci/0000:01:00.0 The register has two masks of 256 bits to denote on which ingress / egress ports the register should operate on. Spectrum-4 has more than 256 ports, so the register was extended by cited commit with a new 'port_page' field. However, when filling the register's payload, the driver specifies the ports as absolute numbers and not relative to the first port of the port page, resulting in memory corruptions [1]. Fix by specifying the ports relative to the first port of the port page. [1] BUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 Read of size 1 at addr ffff8881068cb00f by task devlink/1566 [...] Call Trace: <TASK> dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0 mlxsw_devlink_sb_occ_snapshot+0x75/0xb0 devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0 genl_family_rcv_msg_doit+0x20c/0x300 genl_rcv_msg+0x567/0x800 netlink_rcv_skb+0x170/0x450 genl_rcv+0x2d/0x40 netlink_unicast+0x547/0x830 netlink_sendmsg+0x8d4/0xdb0 __sys_sendto+0x49b/0x510 __x64_sys_sendto+0xe5/0x1c0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [...] Allocated by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 copy_verifier_state+0xbc2/0xfb0 do_check_common+0x2c51/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 1: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x109/0x170 __kasan_slab_free+0x14/0x30 kfree+0xca/0x2b0 free_verifier_state+0xce/0x270 do_check_common+0x4828/0xc7e0 bpf_check+0x5107/0x9960 bpf_prog_load+0xf0e/0x2690 __sys_bpf+0x1a61/0x49d0 __x64_sys_bpf+0x7d/0xc0 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36","https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a","https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e","https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13","https://git.kernel.org/stable/c/942901e0fc74ad4b7992ef7ca9336e68d5fd6d36","https://git.kernel.org/stable/c/bf8781ede7bd9a37c0fcabca78976e61300b5a1a","https://git.kernel.org/stable/c/bfa86a96912faa0b6142a918db88cc0c738a769e","https://git.kernel.org/stable/c/c28947de2bed40217cf256c5d0d16880054fcf13"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50229 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints. | ["https://git.kernel.org/stable/c/1246d86e7bbde265761932c6e2dce28c69cdcb91","https://git.kernel.org/stable/c/58c7f44c7b9e5ac7e3b1e5da2572ed7767a12f38","https://git.kernel.org/stable/c/69548bb663fcb63f9ee0301be808a36b9d78dac3","https://git.kernel.org/stable/c/9aa5d43ac4cace8fb9bd964ff6c23f599dc3cd24","https://git.kernel.org/stable/c/a1686db1e59f8fc016c4c9361e2119dd206f479a","https://git.kernel.org/stable/c/b3a033e3ecd3471248d474ef263aadc0059e516a","https://git.kernel.org/stable/c/c72e0df0b56c1166736dc8eb62070ebb12591447","https://git.kernel.org/stable/c/cc38c596e648575ce58bfc31623a6506eda4b94a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49878 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with "System RAM" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- "CXL Window 0" ------------| |-- "System RAM" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- "System RAM" --||-- "CXL Window 0a" --| Where "CXL Window 0a" is part of the original "CXL Window 0" that isn't covered by "System RAM". | ["https://git.kernel.org/stable/c/06ff97a20b8c9e9d256b0d2c3e87f78f8ccea3de","https://git.kernel.org/stable/c/1d5f85f1b7db79c75c9e07d6571ce2a7bdf725c4","https://git.kernel.org/stable/c/333fbaf6864a4ca031367eb947961a1f3484d337","https://git.kernel.org/stable/c/393331e16ce205e036e58b3d8ca4ee2e635f21d9","https://git.kernel.org/stable/c/4b90d2eb451b357681063ba4552b10b39d7ad885","https://git.kernel.org/stable/c/8a6fef7d22a1d952aed68584d3fcc0d018d2bdc3","https://git.kernel.org/stable/c/927abc5b7d6d2c2e936bec5a2f71d9512c5e72f7","https://git.kernel.org/stable/c/b4afe4183ec77f230851ea139d91e5cf2644c68b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35976 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING syzbot reported an illegal copy in xsk_setsockopt() [1] Make sure to validate setsockopt() @optlen parameter. [1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549 CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fb40587de69 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69 RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006 RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000 R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 </TASK> Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2) The buggy address belongs to the physical page: page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001 raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c: ---truncated--- | ["https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d","https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44","https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa","https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6","https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417","https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c","https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd","https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922","https://git.kernel.org/stable/c/0b45c25d60e38f5c2cb6823f886773a34323306d","https://git.kernel.org/stable/c/237f3cf13b20db183d3706d997eedc3c49eacd44","https://git.kernel.org/stable/c/2a523f14a3f53b46ff0e1fafd215b0bc5f6783aa","https://git.kernel.org/stable/c/2eb979fbb2479bcd7e049f2f9978b6590dd8a0e6","https://git.kernel.org/stable/c/a82984b3c6a7e8c7937dba6e857ddf829d149417","https://git.kernel.org/stable/c/b143e19dc28c3211f050f7848d87d9b0a170e10c","https://git.kernel.org/stable/c/beb99266830520e15fbc6ca8cc5a5240d76851fd","https://git.kernel.org/stable/c/f0a068de65d5b7358e9aff792716afa9333f3922"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52817 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log: 1. Navigate to the directory: /sys/kernel/debug/dri/0 2. Execute command: cat amdgpu_regs_smc 3. Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ en ---truncated--- | ["https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455","https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9","https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad","https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736","https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288","https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996","https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398","https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a","https://git.kernel.org/stable/c/174f62a0aa15c211e60208b41ee9e7cdfb73d455","https://git.kernel.org/stable/c/437e0fa907ba39b4d7eda863c03ea9cf48bd93a9","https://git.kernel.org/stable/c/5104fdf50d326db2c1a994f8b35dcd46e63ae4ad","https://git.kernel.org/stable/c/6c1b3d89a2dda79881726bb6e37af19c0936d736","https://git.kernel.org/stable/c/820daf9ffe2b0afb804567b10983fb38bc5ae288","https://git.kernel.org/stable/c/ba3c0796d292de84f2932cc5bbb0f771fc720996","https://git.kernel.org/stable/c/bf2d51eedf03bd61e3556e35d74d49e2e6112398","https://git.kernel.org/stable/c/f475d5502f33a6c5b149b0afe96316ad1962a64a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50275 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled | // task->fpsimd_cpu is 0. | // per_cpu_ptr(&fpsimd_last_state, 0) is task. | | ... | | // Preempted; migrated from CPU 0 to CPU 1. | // TIF_FOREIGN_FPSTATE is set. | | get_cpu_fpsimd_context(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | put_cpu_fpsimd_context(); | | // Preempted; migrated from CPU 1 to CPU 0. | // task->fpsimd_cpu is still 0 | // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then: | // - Stale HW state is reused (with SVE traps enabled) | // - TIF_FOREIGN_FPSTATE is cleared | // - A return to userspace skips HW state restore | } Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is set by calling fpsimd_flush_task_state() to detach from the saved CPU state. This ensures that a subsequent context switch will not reuse the stale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the new state to be reloaded from memory prior to a return to userspace. | ["https://git.kernel.org/stable/c/51d11ea0250d6ee461987403bbfd4b2abb5613a7","https://git.kernel.org/stable/c/51d3d80a6dc314982a9a0aeb0961085922a1aa15","https://git.kernel.org/stable/c/751ecf6afd6568adc98f2a6052315552c0483d18","https://git.kernel.org/stable/c/de529504b3274d57caf8f66800b714b0d3ee235a","https://git.kernel.org/stable/c/fa9ce027b3ce37a2bb173bf2553b5caa438fd8c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26882 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b | ["https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a","https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a","https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80","https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3","https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0","https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1","https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b","https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5","https://git.kernel.org/stable/c/5c03387021cfa3336b97e0dcba38029917a8af2a","https://git.kernel.org/stable/c/60044ab84836359534bd7153b92e9c1584140e4a","https://git.kernel.org/stable/c/77fd5294ea09b21f6772ac954a121b87323cec80","https://git.kernel.org/stable/c/b0ec2abf98267f14d032102551581c833b0659d3","https://git.kernel.org/stable/c/c4c857723b37c20651300b3de4ff25059848b4b0","https://git.kernel.org/stable/c/ca914f1cdee8a85799942c9b0ce5015bbd6844e1","https://git.kernel.org/stable/c/ec6bb01e02cbd47781dd90775b631a1dc4bd9d2b","https://git.kernel.org/stable/c/f6723d8dbfdc10c784a56748f86a9a3cd410dbd5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241220-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52905 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix resource leakage in VF driver unbind resources allocated like mcam entries to support the Ntuple feature and hash tables for the tc feature are not getting freed in driver unbind. This patch fixes the issue. | ["https://git.kernel.org/stable/c/53da7aec32982f5ee775b69dce06d63992ce4af3","https://git.kernel.org/stable/c/c8ca0ad10df08ea36bcac1288062d567d22604c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix I/O page table memory leak The current logic updates the I/O page table mode for the domain before calling the logic to free memory used for the page table. This results in IOMMU page table memory leak, and can be observed when launching VM w/ pass-through devices. Fix by freeing the memory used for page table before updating the mode. | ["https://git.kernel.org/stable/c/378e2fe1eb58d5c2ed55c8fe5e11f9db5033cdd6","https://git.kernel.org/stable/c/6b0b2d9a6a308bcd9300c2d83000a82812c56cea","https://git.kernel.org/stable/c/c78627f757e37c2cf386b59c700c4e1574988597"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52910 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/iova: Fix alloc iova overflows issue In __alloc_and_insert_iova_range, there is an issue that retry_pfn overflows. The value of iovad->anchor.pfn_hi is ~0UL, then when iovad->cached_node is iovad->anchor, curr_iova->pfn_hi + 1 will overflow. As a result, if the retry logic is executed, low_pfn is updated to 0, and then new_pfn < low_pfn returns false to make the allocation successful. This issue occurs in the following two situations: 1. The first iova size exceeds the domain size. When initializing iova domain, iovad->cached_node is assigned as iovad->anchor. For example, the iova domain size is 10M, start_pfn is 0x1_F000_0000, and the iova size allocated for the first time is 11M. The following is the log information, new->pfn_lo is smaller than iovad->cached_node. Example log as follows: [ 223.798112][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00 [ 223.799590][T1705487] sh: [name:iova&]__alloc_and_insert_iova_range success start_pfn:0x1f0000,new->pfn_lo:0x1efe00,new->pfn_hi:0x1f08ff 2. The node with the largest iova->pfn_lo value in the iova domain is deleted, iovad->cached_node will be updated to iovad->anchor, and then the alloc iova size exceeds the maximum iova size that can be allocated in the domain. After judging that retry_pfn is less than limit_pfn, call retry_pfn+1 to fix the overflow issue. | ["https://git.kernel.org/stable/c/61cbf790e7329ed78877560be7136f0b911bba7f","https://git.kernel.org/stable/c/c929a230c84441e400c32e7b7b4ab763711fb63e","https://git.kernel.org/stable/c/dcdb3ba7e2a8caae7bfefd603bc22fd0ce9a389c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46780 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect references to superblock parameters exposed in sysfs The superblock buffers of nilfs2 can not only be overwritten at runtime for modifications/repairs, but they are also regularly swapped, replaced during resizing, and even abandoned when degrading to one side due to backing device issues. So, accessing them requires mutual exclusion using the reader/writer semaphore "nilfs->ns_sem". Some sysfs attribute show methods read this superblock buffer without the necessary mutual exclusion, which can cause problems with pointer dereferencing and memory access, so fix it. | ["https://git.kernel.org/stable/c/157c0d94b4c40887329418c70ef4edd1a8d6b4ed","https://git.kernel.org/stable/c/19cfeba0e4b8eda51484fcf8cf7d150418e1d880","https://git.kernel.org/stable/c/683408258917541bdb294cd717c210a04381931e","https://git.kernel.org/stable/c/8c6e43b3d5f109cf9c61bc188fcc8175404e924f","https://git.kernel.org/stable/c/962562d4c70c5cdeb4e955d63ff2017c4eca1aad","https://git.kernel.org/stable/c/b14e7260bb691d7f563f61da07d61e3c8b59a614","https://git.kernel.org/stable/c/b90beafac05931cbfcb6b1bd4f67c1923f47040e","https://git.kernel.org/stable/c/ba97ba173f9625d5f34a986088979eae8b80d38e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23454 | Medium | N/A | cbq_classify in net/sched/sch_cbq.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service (slab-out-of-bounds read) because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results). | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=caa4b35b4317d5147b3ab0fbdc9c075c7d2e9c12","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48835 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Page fault in reply q processing A page fault was encountered in mpt3sas on a LUN reset error path: [ 145.763216] mpt3sas_cm1: Task abort tm failed: handle(0x0002),timeout(30) tr_method(0x0) smid(3) msix_index(0) [ 145.778932] scsi 1:0:0:0: task abort: FAILED scmd(0x0000000024ba29a2) [ 145.817307] scsi 1:0:0:0: attempting device reset! scmd(0x0000000024ba29a2) [ 145.827253] scsi 1:0:0:0: [sg1] tag#2 CDB: Receive Diagnostic 1c 01 01 ff fc 00 [ 145.837617] scsi target1:0:0: handle(0x0002), sas_address(0x500605b0000272b9), phy(0) [ 145.848598] scsi target1:0:0: enclosure logical id(0x500605b0000272b8), slot(0) [ 149.858378] mpt3sas_cm1: Poll ReplyDescriptor queues for completion of smid(0), task_type(0x05), handle(0x0002) [ 149.875202] BUG: unable to handle page fault for address: 00000007fffc445d [ 149.885617] #PF: supervisor read access in kernel mode [ 149.894346] #PF: error_code(0x0000) - not-present page [ 149.903123] PGD 0 P4D 0 [ 149.909387] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 149.917417] CPU: 24 PID: 3512 Comm: scsi_eh_1 Kdump: loaded Tainted: G S O 5.10.89-altav-1 #1 [ 149.934327] Hardware name: DDN 200NVX2 /200NVX2-MB , BIOS ATHG2.2.02.01 09/10/2021 [ 149.951871] RIP: 0010:_base_process_reply_queue+0x4b/0x900 [mpt3sas] [ 149.961889] Code: 0f 84 22 02 00 00 8d 48 01 49 89 fd 48 8d 57 38 f0 0f b1 4f 38 0f 85 d8 01 00 00 49 8b 45 10 45 31 e4 41 8b 55 0c 48 8d 1c d0 <0f> b6 03 83 e0 0f 3c 0f 0f 85 a2 00 00 00 e9 e6 01 00 00 0f b7 ee [ 149.991952] RSP: 0018:ffffc9000f1ebcb8 EFLAGS: 00010246 [ 150.000937] RAX: 0000000000000055 RBX: 00000007fffc445d RCX: 000000002548f071 [ 150.011841] RDX: 00000000ffff8881 RSI: 0000000000000001 RDI: ffff888125ed50d8 [ 150.022670] RBP: 0000000000000000 R08: 0000000000000000 R09: c0000000ffff7fff [ 150.033445] R10: ffffc9000f1ebb68 R11: ffffc9000f1ebb60 R12: 0000000000000000 [ 150.044204] R13: ffff888125ed50d8 R14: 0000000000000080 R15: 34cdc00034cdea80 [ 150.054963] FS: 0000000000000000(0000) GS:ffff88dfaf200000(0000) knlGS:0000000000000000 [ 150.066715] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 150.076078] CR2: 00000007fffc445d CR3: 000000012448a006 CR4: 0000000000770ee0 [ 150.086887] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 150.097670] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 150.108323] PKRU: 55555554 [ 150.114690] Call Trace: [ 150.120497] ? printk+0x48/0x4a [ 150.127049] mpt3sas_scsih_issue_tm.cold.114+0x2e/0x2b3 [mpt3sas] [ 150.136453] mpt3sas_scsih_issue_locked_tm+0x86/0xb0 [mpt3sas] [ 150.145759] scsih_dev_reset+0xea/0x300 [mpt3sas] [ 150.153891] scsi_eh_ready_devs+0x541/0x9e0 [scsi_mod] [ 150.162206] ? __scsi_host_match+0x20/0x20 [scsi_mod] [ 150.170406] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.178925] ? blk_mq_tagset_busy_iter+0x45/0x60 [ 150.186638] ? scsi_try_target_reset+0x90/0x90 [scsi_mod] [ 150.195087] scsi_error_handler+0x3a5/0x4a0 [scsi_mod] [ 150.203206] ? __schedule+0x1e9/0x610 [ 150.209783] ? scsi_eh_get_sense+0x210/0x210 [scsi_mod] [ 150.217924] kthread+0x12e/0x150 [ 150.224041] ? kthread_worker_fn+0x130/0x130 [ 150.231206] ret_from_fork+0x1f/0x30 This is caused by mpt3sas_base_sync_reply_irqs() using an invalid reply_q pointer outside of the list_for_each_entry() loop. At the end of the full list traversal the pointer is invalid. Move the _base_process_reply_queue() call inside of the loop. | ["https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f","https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05","https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3","https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413","https://git.kernel.org/stable/c/0cd2dd4bcf4abc812148c4943f966a3c8dccb00f","https://git.kernel.org/stable/c/3916e33b917581e2b2086e856c291cb86ea98a05","https://git.kernel.org/stable/c/69ad4ef868c1fc7609daa235dfa46d28ba7a3ba3","https://git.kernel.org/stable/c/98e7a654a5bebaf1a28e987af5e44c002544a413"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52650 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for of_find_device_by_node Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc","https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80","https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6","https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976","https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129","https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d","https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d","https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9","https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5","https://git.kernel.org/stable/c/3169eaf1365541fd8e521091010c44fbe14691fc","https://git.kernel.org/stable/c/47a13d0b9d8527518639ab5c39667f69d6203e80","https://git.kernel.org/stable/c/50c0ad785a780c72a2fdaba10b38c645ffb4eae6","https://git.kernel.org/stable/c/52aa507148c4aad41436e2005d742ffcafad9976","https://git.kernel.org/stable/c/92003981a6df5dc84af8a5904f8ee112fa324129","https://git.kernel.org/stable/c/93128052bf832359531c3c0a9e3567b2b8682a2d","https://git.kernel.org/stable/c/afe6fcb9775882230cd29b529203eabd5d2a638d","https://git.kernel.org/stable/c/c5d2342d24ef6e08fc90a529fe3dc59de421a2b9","https://git.kernel.org/stable/c/f05631a8525c3b5e5994ecb1304d2d878956c0f5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26966 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | ["https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99","https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9","https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2","https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8","https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38","https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03","https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f","https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d","https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0","https://git.kernel.org/stable/c/185de0b7cdeaad8b89ebd4c8a258ff2f21adba99","https://git.kernel.org/stable/c/3aedcf3755c74dafc187eb76acb04e3e6348b1a9","https://git.kernel.org/stable/c/5533686e99b04994d7c4877dc0e4282adc9444a2","https://git.kernel.org/stable/c/5638330150db2cc30b53eed04e481062faa3ece8","https://git.kernel.org/stable/c/7e5432401536117c316d7f3b21d46b64c1514f38","https://git.kernel.org/stable/c/9b4c4546dd61950e80ffdca1bf6925f42b665b03","https://git.kernel.org/stable/c/a09aecb6cb482de88301c43bf00a6c8726c4d34f","https://git.kernel.org/stable/c/a903cfd38d8dee7e754fb89fd1bebed99e28003d","https://git.kernel.org/stable/c/b2dfb216f32627c2f6a8041f2d9d56d102ab87c0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays The frequency table arrays are supposed to be terminated with an empty element. Add such entry to the end of the arrays where it is missing in order to avoid possible out-of-bound access when the table is traversed by functions like qcom_find_freq() or qcom_find_freq_floor(). Only compile tested. | ["https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429","https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94","https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe","https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f","https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d","https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566","https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255","https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27","https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9","https://git.kernel.org/stable/c/1040ef5ed95d6fd2628bad387d78a61633e09429","https://git.kernel.org/stable/c/83fe1bbd9e259ad109827ccfbfc2488e0dea8e94","https://git.kernel.org/stable/c/851cc19bdb02556fb13629b3e4fef6f2bdb038fe","https://git.kernel.org/stable/c/9de184d4e557d550fb0b7b833b676bda4f269e4f","https://git.kernel.org/stable/c/b6b31b4c67ea6bd9222e5b73b330554c57f2f90d","https://git.kernel.org/stable/c/be9e2752d823eca1d5af67014a1844a9176ff566","https://git.kernel.org/stable/c/dd92b159c506804ac57adf3742d9728298bb1255","https://git.kernel.org/stable/c/e117c6e2d1617520f5f7d7f6f6b395f01d8b5a27","https://git.kernel.org/stable/c/fc3ac2fcd0a7fad63eba1b359490a4b81720d0f9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27046 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again. | ["https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5","https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d","https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642","https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002","https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f","https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2","https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d","https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3","https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e","https://git.kernel.org/stable/c/0d387dc503f9a53e6d1f6e9dd0292d38f083eba5","https://git.kernel.org/stable/c/3b1e8a617eb0f4cdc19def530047a95b5abde07d","https://git.kernel.org/stable/c/408ba7fd04f959c61b50db79c983484312fea642","https://git.kernel.org/stable/c/84e95149bd341705f0eca6a7fcb955c548805002","https://git.kernel.org/stable/c/928705e341010dd910fdece61ccb974f494a758f","https://git.kernel.org/stable/c/9d8eb1238377cd994829f9162ae396a84ae037b2","https://git.kernel.org/stable/c/c8df9203bf22c66fa26e8d8c7f8ce181cf88099d","https://git.kernel.org/stable/c/c9b4e220dd18f79507803f38a55d53b483f6c9c3","https://git.kernel.org/stable/c/d746889db75a76aeee95fb705b8e1ac28c684a2e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27074 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |-> go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. | ["https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159","https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4","https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3","https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5","https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073","https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12","https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661","https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3","https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975","https://git.kernel.org/stable/c/291cda0b805fc0d6e90d201710311630c8667159","https://git.kernel.org/stable/c/7405a0d4442792988e9ae834e7d84f9d163731a4","https://git.kernel.org/stable/c/790fa2c04dfb9f095ec372bf17909424d6e864b3","https://git.kernel.org/stable/c/7f11dd3d165b178e738fe73dfeea513e383bedb5","https://git.kernel.org/stable/c/b49fe84c6cefcc1c2336d793b53442e716c95073","https://git.kernel.org/stable/c/b9b683844b01d171a72b9c0419a2d760d946ee12","https://git.kernel.org/stable/c/d43988a23c32588ccd0c74219637afb96cd78661","https://git.kernel.org/stable/c/e04d15c8bb3e111dd69f98894acd92d63e87aac3","https://git.kernel.org/stable/c/f31c1cc37411f5f7bcb266133f9a7e1b4bdf2975","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27077 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name. | ["https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4","https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d","https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333","https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458","https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211","https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d","https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f","https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2","https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef","https://git.kernel.org/stable/c/0175f2d34c85744f9ad6554f696cf0afb5bd04e4","https://git.kernel.org/stable/c/0c9550b032de48d6a7fa6a4ddc09699d64d9300d","https://git.kernel.org/stable/c/3dd8abb0ed0e0a7c66d6d677c86ccb188cc39333","https://git.kernel.org/stable/c/5dc319cc3c4f7b74f7dfba349aa26f87efb52458","https://git.kernel.org/stable/c/8f94b49a5b5d386c038e355bef6347298aabd211","https://git.kernel.org/stable/c/90029b9c979b60de5cb2b70ade4bbf61d561bc5d","https://git.kernel.org/stable/c/9c23ef30e840fedc66948299509f6c2777c9cf4f","https://git.kernel.org/stable/c/afd2a82fe300032f63f8be5d6cd6981e75f8bbf2","https://git.kernel.org/stable/c/dc866b69cc51af9b8509b4731b8ce2a4950cd0ef","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27078 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0. | ["https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77","https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09","https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941","https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7","https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d","https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511","https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79","https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c","https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28","https://git.kernel.org/stable/c/0de691ff547d86dd54c24b40a81f9c925df8dd77","https://git.kernel.org/stable/c/31096da07933598da8522c54bd007376fb152a09","https://git.kernel.org/stable/c/4c86c772fef06f5d7a66151bac42366825db0941","https://git.kernel.org/stable/c/622b1cf38521569869c8f7b9fbe9e4f1a289add7","https://git.kernel.org/stable/c/6bf5c2fade8ed53b2d26fa9875e5b04f36c7145d","https://git.kernel.org/stable/c/770a57922ce36a8476c43f7400b6501c554ea511","https://git.kernel.org/stable/c/8269ab16415f2065cd792c49b0475543936cbd79","https://git.kernel.org/stable/c/8cf9c5051076e0eb958f4361d50d8b0c3ee6691c","https://git.kernel.org/stable/c/94303a06e1852a366e9671fff46d19459f88cb28","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35811 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233 In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker: ->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker); If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is : brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg); While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker. Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach. [arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free] | ["https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb","https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744","https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a","https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169","https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a","https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731","https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1","https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa","https://git.kernel.org/stable/c/0a7591e14a8da794d0b93b5d1c6254ccb23adacb","https://git.kernel.org/stable/c/0b812f706fd7090be74812101114a0e165b36744","https://git.kernel.org/stable/c/0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://git.kernel.org/stable/c/190794848e2b9d15de92d502b6ac652806904f5a","https://git.kernel.org/stable/c/202c503935042272e2f9e1bb549d5f69a8681169","https://git.kernel.org/stable/c/6678a1e7d896c00030b31491690e8ddc9a90767a","https://git.kernel.org/stable/c/8c36205123dc57349b59b4f1a2301eb278cbc731","https://git.kernel.org/stable/c/8e3f03f4ef7c36091f46e7349096efb5a2cdb3a1","https://git.kernel.org/stable/c/bacb8c3ab86dcd760c15903fcee58169bc3026aa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35828 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). | ["https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9","https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a","https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab","https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186","https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf","https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591","https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3","https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2","https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7","https://git.kernel.org/stable/c/4d99d267da3415db2124029cb5a6d2d955ca43f9","https://git.kernel.org/stable/c/5f0e4aede01cb01fa633171f0533affd25328c3a","https://git.kernel.org/stable/c/8e243ac649c10922a6b4855170eaefe4c5b3faab","https://git.kernel.org/stable/c/96481624fb5a6319079fb5059e46dbce43a90186","https://git.kernel.org/stable/c/bea9573c795acec5614d4ac2dcc7b3b684cea5bf","https://git.kernel.org/stable/c/d219724d4b0ddb8ec7dfeaed5989f23edabaf591","https://git.kernel.org/stable/c/da10f6b7918abd5b4bc5c9cb66f0fc6763ac48f3","https://git.kernel.org/stable/c/e888c4461e109f7b93c3522afcbbaa5a8fdf29d2","https://git.kernel.org/stable/c/f0dd27314c7afe34794c2aa19dd6f2d30eb23bc7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43828 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem! | ["https://git.kernel.org/stable/c/0619f7750f2b178a1309808832ab20d85e0ad121","https://git.kernel.org/stable/c/181e63cd595c688194e07332f9944b3a63193de2","https://git.kernel.org/stable/c/5ed0496e383cb6de120e56991385dce70bbb87c1","https://git.kernel.org/stable/c/81f819c537d29932e4b9267f02411cbc8b355178","https://git.kernel.org/stable/c/907c3fe532253a6ef4eb9c4d67efb71fab58c706","https://git.kernel.org/stable/c/c6e67df64783e99a657ef2b8c834ba2bf54c539c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52814 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential null pointer derefernce The amdgpu_ras_get_context may return NULL if device not support ras feature, so add check before using. | ["https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1","https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1","https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111","https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b","https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe","https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2","https://git.kernel.org/stable/c/80285ae1ec8717b597b20de38866c29d84d321a1","https://git.kernel.org/stable/c/9b70fc7d70e8ef7c4a65034c9487f58609e708a1","https://git.kernel.org/stable/c/b0702ee4d811708251cdf54d4a1d3e888d365111","https://git.kernel.org/stable/c/b93a25de28af153312f0fc979b0663fc4bd3442b","https://git.kernel.org/stable/c/c11cf5e117f50f5a767054600885acd981449afe","https://git.kernel.org/stable/c/da46e63482fdc5e35c008865c22ac64027f6f0c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35852 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash work The rehash delayed work is rescheduled with a delay if the number of credits at end of the work is not negative as supposedly it means that the migration ended. Otherwise, it is rescheduled immediately. After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash" the above is no longer accurate as a non-negative number of credits is no longer indicative of the migration being done. It can also happen if the work encountered an error in which case the migration will resume the next time the work is scheduled. The significance of the above is that it is possible for the work to be pending and associated with hints that were allocated when the migration started. This leads to the hints being leaked [1] when the work is canceled while pending as part of ACL region dismantle. Fix by freeing the hints if hints are associated with a work that was canceled while pending. Blame the original commit since the reliance on not having a pending work associated with hints is fragile. [1] unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30 | ["https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758","https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04","https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f","https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d","https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d","https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab","https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5","https://git.kernel.org/stable/c/51cefc9da400b953fee749c9e5d26cd4a2b5d758","https://git.kernel.org/stable/c/5bfe7bf9656ed2633718388f12b7c38b86414a04","https://git.kernel.org/stable/c/63d814d93c5cce4c18284adc810028f28dca493f","https://git.kernel.org/stable/c/857ed800133ffcfcee28582090b63b0cbb8ba59d","https://git.kernel.org/stable/c/d72dd6fcd7886d0523afbab8b4a4b22d17addd7d","https://git.kernel.org/stable/c/de1aaefa75be9d0ec19c9a3e0e2f9696de20c6ab","https://git.kernel.org/stable/c/fb4e2b70a7194b209fc7320bbf33b375f7114bd5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21735 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Add bounds checking in nci_hci_create_pipe() The "pipe" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, nci_hci_connect_gate(). | ["https://git.kernel.org/stable/c/10b3f947b609713e04022101f492d288a014ddfa","https://git.kernel.org/stable/c/110b43ef05342d5a11284cc8b21582b698b4ef1c","https://git.kernel.org/stable/c/172cdfc3a5ea20289c58fb73dadc6fd4a8784a4e","https://git.kernel.org/stable/c/2ae4bade5a64d126bd18eb66bd419005c5550218","https://git.kernel.org/stable/c/59c7ed20217c0939862fbf8145bc49d5b3a13f4f","https://git.kernel.org/stable/c/674e17c5933779a8bf5c15d596fdfcb5ccdebbc2","https://git.kernel.org/stable/c/bd249109d266f1d52548c46634a15b71656e0d44","https://git.kernel.org/stable/c/d5a461c315e5ff92657f84d8ba50caa5abf5c22a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46804 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add array index check for hdcp ddc access [Why] Coverity reports OVERRUN warning. Do not check if array index valid. [How] Check msg_id valid and valid array index. | ["https://git.kernel.org/stable/c/0ee4387c5a4b57ec733c3fb4365188d5979cd9c7","https://git.kernel.org/stable/c/2a63c90c7a90ab2bd23deebc2814fc5b52abf6d2","https://git.kernel.org/stable/c/4e70c0f5251c25885c31ee84a31f99a01f7cf50e","https://git.kernel.org/stable/c/8b5ccf3d011969417be653b5a145c72dbd30472c","https://git.kernel.org/stable/c/a3b5ee22a9d3a30045191da5678ca8451ebaea30","https://git.kernel.org/stable/c/f338f99f6a04d03c802087d82a83561cbd5bdc99"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46844 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: um: line: always fill *error_out in setup_one_line() The pointer isn't initialized by callers, but I have encountered cases where it's still printed; initialize it in all possible cases in setup_one_line(). | ["https://git.kernel.org/stable/c/289979d64573f43df1d0e6bc6435de63a0d69cdf","https://git.kernel.org/stable/c/3bedb7ce080690d0d6172db790790c1219bcbdd5","https://git.kernel.org/stable/c/43f782c27907f306c664b6614fd6f264ac32cce6","https://git.kernel.org/stable/c/824ac4a5edd3f7494ab1996826c4f47f8ef0f63d","https://git.kernel.org/stable/c/96301fdc2d533a196197c055af875fe33d47ef84","https://git.kernel.org/stable/c/c8944d449fda9f58c03bd99649b2df09948fc874","https://git.kernel.org/stable/c/ec5b47a370177d79ae7773858042c107e21f8ecc","https://git.kernel.org/stable/c/fc843d3837ebcb1c16d3768ef3eb55e25d5331f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50143 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udf: fix uninit-value use in udf_get_fileshortad Check for overflow when computing alen in udf_current_aext to mitigate later uninit-value use in udf_get_fileshortad KMSAN bug[1]. After applying the patch reproducer did not trigger any issue[2]. [1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df [2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000 | ["https://git.kernel.org/stable/c/1ac49babc952f48d82676979b20885e480e69be8","https://git.kernel.org/stable/c/264db9d666ad9a35075cc9ed9ec09d021580fbb1","https://git.kernel.org/stable/c/417bd613bdbe791549f7687bb1b9b8012ff111c2","https://git.kernel.org/stable/c/4fc0d8660e391dcd8dde23c44d702be1f6846c61","https://git.kernel.org/stable/c/5eb76fb98b3335aa5cca6a7db2e659561c79c32b","https://git.kernel.org/stable/c/72e445df65a0aa9066c6fe2b8736ba2fcca6dac7","https://git.kernel.org/stable/c/e52e0b92ed31dc62afbda15c243dcee0bb5bb58d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50180 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/11c0d49093b82f6c547fd419c41a982d26bdf5ef","https://git.kernel.org/stable/c/252f147b1826cbb30ae0304cf86b66d3bb12b743","https://git.kernel.org/stable/c/41cf6f26abe4f491b694c54bd1aa2530369b7510","https://git.kernel.org/stable/c/433c84c8495008922534c5cafdae6ff970fb3241","https://git.kernel.org/stable/c/57c4f4db0a194416da237fd09dad9527e00cb587","https://git.kernel.org/stable/c/688872c4ea4a528cd6a057d545c83506b533ee1f","https://git.kernel.org/stable/c/889304120ecb2ca30674d89cd4ef15990b6a571c","https://git.kernel.org/stable/c/9cf14f5a2746c19455ce9cb44341b5527b5e19c3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46725 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds write warning Check the ring type value to fix the out-of-bounds write warning | ["https://git.kernel.org/stable/c/130bee397b9cd52006145c87a456fd8719390cb5","https://git.kernel.org/stable/c/919f9bf9997b8dcdc132485ea96121e7d15555f9","https://git.kernel.org/stable/c/a60d1f7ff62e453dde2d3b4907e178954d199844","https://git.kernel.org/stable/c/be1684930f5262a622d40ce7a6f1423530d87f89","https://git.kernel.org/stable/c/c253b87c7c37ec40a2e0c84e4a6b636ba5cd66b2","https://git.kernel.org/stable/c/cf2db220b38301b6486a0f11da24a0f317de558c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49022 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac8021: fix possible oob access in ieee80211_get_rate_duration Fix possible out-of-bound access in ieee80211_get_rate_duration routine as reported by the following UBSAN report: UBSAN: array-index-out-of-bounds in net/mac80211/airtime.c:455:47 index 15 is out of range for type 'u16 [12]' CPU: 2 PID: 217 Comm: kworker/u32:10 Not tainted 6.1.0-060100rc3-generic Hardware name: Acer Aspire TC-281/Aspire TC-281, BIOS R01-A2 07/18/2017 Workqueue: mt76 mt76u_tx_status_data [mt76_usb] Call Trace: <TASK> show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x43 __ubsan_handle_out_of_bounds.cold+0x42/0x47 ieee80211_get_rate_duration.constprop.0+0x22f/0x2a0 [mac80211] ? ieee80211_tx_status_ext+0x32e/0x640 [mac80211] ieee80211_calc_rx_airtime+0xda/0x120 [mac80211] ieee80211_calc_tx_airtime+0xb4/0x100 [mac80211] mt76x02_send_tx_status+0x266/0x480 [mt76x02_lib] mt76x02_tx_status_data+0x52/0x80 [mt76x02_lib] mt76u_tx_status_data+0x67/0xd0 [mt76_usb] process_one_work+0x225/0x400 worker_thread+0x50/0x3e0 ? process_one_work+0x400/0x400 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 | ["https://git.kernel.org/stable/c/0184ede0ec61b9cd075babfaa45081b1bf322234","https://git.kernel.org/stable/c/3e8f7abcc3473bc9603323803aeaed4ffcc3a2ab","https://git.kernel.org/stable/c/59b54f0563b6546c94bdb6823d3b382c75407019","https://git.kernel.org/stable/c/f0fcad4c7201ecfaa17357f4ce0c50b4708df22d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47670 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: add bounds checking to ocfs2_xattr_find_entry() Add a paranoia check to make sure it doesn't stray beyond valid memory region containing ocfs2 xattr entries when scanning for a match. It will prevent out-of-bound access in case of crafted images. | ["https://git.kernel.org/stable/c/1f6e167d6753fe3ea493cdc7f7de8d03147a4d39","https://git.kernel.org/stable/c/34759b7e4493d7337cbc414c132cef378c492a2c","https://git.kernel.org/stable/c/5bbe51eaf01a5dd6fb3f0dea81791e5dbc6dc6dd","https://git.kernel.org/stable/c/60c0d36189bad58b1a8e69af8781d90009559ea1","https://git.kernel.org/stable/c/8e7bef408261746c160853fc27df3139659f5f77","https://git.kernel.org/stable/c/9b32539590a8e6400ac2f6e7cf9cbb8e08711a2f","https://git.kernel.org/stable/c/9e3041fecdc8f78a5900c3aa51d3d756e73264d6","https://git.kernel.org/stable/c/b49a786beb11ff740cb9e0c20b999c2a0e1729c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49889 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality. | ["https://git.kernel.org/stable/c/2eba3b0cc5b8de624918d21f32b5b8db59a90b39","https://git.kernel.org/stable/c/34b2096380ba475771971a778a478661a791aa15","https://git.kernel.org/stable/c/4999fed877bb64e3e7f9ab9996de2ca983c41928","https://git.kernel.org/stable/c/4e2524ba2ca5f54bdbb9e5153bea00421ef653f5","https://git.kernel.org/stable/c/8b114f2cc7dd5d36729d040b68432fbd0f0a8868","https://git.kernel.org/stable/c/b0cb4561fc4284d04e69c8a66c8504928ab2484e","https://git.kernel.org/stable/c/d483c7cc1796bd6a80e7b3a8fd494996260f6b67"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49930 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/01b77f5ee11c89754fb836af8f76799d3b72ae2f","https://git.kernel.org/stable/c/0f26f26944035ec67546a944f182cbad6577a9c0","https://git.kernel.org/stable/c/4dd732893bd38cec51f887244314e2b47f0d658f","https://git.kernel.org/stable/c/6045ef5b4b00fee3629689f791992900a1c94009","https://git.kernel.org/stable/c/69f253e46af98af17e3efa3e5dfa72fcb7d1983d","https://git.kernel.org/stable/c/73e235728e515faccc104b0153b47d0f263b3344","https://git.kernel.org/stable/c/7a552bc2f3efe2aaf77a85cb34cdf4a63d81a1a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49936 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe. | ["https://git.kernel.org/stable/c/0fa5e94a1811d68fbffa0725efe6d4ca62c03d12","https://git.kernel.org/stable/c/143edf098b80669d05245b2f2367dd156a83a2c5","https://git.kernel.org/stable/c/3c4423b0c4b98213b3438e15061e1d08220e6982","https://git.kernel.org/stable/c/54d8639af5568fc41c0e274fc3ec9cf86c59fcbb","https://git.kernel.org/stable/c/a0465723b8581cad27164c9073fd780904cd22d4","https://git.kernel.org/stable/c/a7f0073fcd12ed7de185ef2c0af9d0fa1ddef22c","https://git.kernel.org/stable/c/d408889d4b54f5501e4becc4dbbb9065143fbf4e","https://git.kernel.org/stable/c/efcff6ce7467f01f0753609f420333f3f2ceceda"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50055 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free. | ["https://git.kernel.org/stable/c/4797953712214ea57a437443bb0ad6d1e0646d70","https://git.kernel.org/stable/c/5be4bc1c73ca389a96d418a52054d897c6fe6d21","https://git.kernel.org/stable/c/87bc3cb23c56de2c5e14a58d87cf953e7a2508f8","https://git.kernel.org/stable/c/9ce15f68abedfae7ae0a35e95895aeddfd0f0c6a","https://git.kernel.org/stable/c/bfa54a793ba77ef696755b66f3ac4ed00c7d1248","https://git.kernel.org/stable/c/d885c464c25018b81a6b58f5d548fc2e3ef87dd1","https://git.kernel.org/stable/c/fc1f391a71a3ee88291e205cffd673fe24d99266"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50242 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release | ["https://git.kernel.org/stable/c/031d6f608290c847ba6378322d0986d08d1a645a","https://git.kernel.org/stable/c/542532afe249588ae88d8409d4bf861c315f8862","https://git.kernel.org/stable/c/550ef40fa6366d5d11b122e5f36b1f9aa20c087e","https://git.kernel.org/stable/c/82685eb6ca1db2bd11190451085bcb86ed03aa24","https://git.kernel.org/stable/c/d1ac7e2620302e3e49573df39bd4e868e8b4962a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50283 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp(). | ["https://git.kernel.org/stable/c/1b6ad475d4ed577d34e0157eb507be00c588bf5c","https://git.kernel.org/stable/c/b8fc56fbca7482c1e5c0e3351c6ae78982e25ada","https://git.kernel.org/stable/c/c6cdc08c25a868a08068dfc319fa9fce982b8e7f","https://git.kernel.org/stable/c/cb645064e0811053c94e86677f2e58ed29359d62","https://git.kernel.org/stable/c/f7557bbca40d4ca8bb1c6c940ac6c95078bd0827"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44940 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fou: remove warn in gue_gro_receive on unsupported protocol Drop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type is not known or does not have a GRO handler. Such a packet is easily constructed. Syzbot generates them and sets off this warning. Remove the warning as it is expected and not actionable. The warning was previously reduced from WARN_ON to WARN_ON_ONCE in commit 270136613bf7 ("fou: Do WARN_ON_ONCE in gue_gro_receive for bad proto callbacks"). | ["https://git.kernel.org/stable/c/3db4395332e7050ef9ddeb3052e6b5019f2a2a59","https://git.kernel.org/stable/c/440ab7f97261bc28501636a13998e1b1946d2e79","https://git.kernel.org/stable/c/5a2e37bc648a2503bf6d687aed27b9f4455d82eb","https://git.kernel.org/stable/c/a925a200299a6dfc7c172f54da6f374edc930053","https://git.kernel.org/stable/c/b1453a5616c7bd8acd90633ceba4e59105ba3b51","https://git.kernel.org/stable/c/dd89a81d850fa9a65f67b4527c0e420d15bf836c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57798 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/dp_mst: Ensure mst_primary pointer is valid in drm_dp_mst_handle_up_req() While receiving an MST up request message from one thread in drm_dp_mst_handle_up_req(), the MST topology could be removed from another thread via drm_dp_mst_topology_mgr_set_mst(false), freeing mst_primary and setting drm_dp_mst_topology_mgr::mst_primary to NULL. This could lead to a NULL deref/use-after-free of mst_primary in drm_dp_mst_handle_up_req(). Avoid the above by holding a reference for mst_primary in drm_dp_mst_handle_up_req() while it's used. v2: Fix kfreeing the request if getting an mst_primary reference fails. | ["https://git.kernel.org/stable/c/9735d40f5fde9970aa46e828ecc85c32571d58a2","https://git.kernel.org/stable/c/ce55818b2d3a999f886af91679589e4644ff1dc8","https://git.kernel.org/stable/c/e54b00086f7473dbda1a7d6fc47720ced157c6a8","https://git.kernel.org/stable/c/f61b2e5e7821f868d6afc22382a66a30ee780ba0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46871 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it. | ["https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37","https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7","https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0","https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98","https://git.kernel.org/stable/c/e1896f381d27466c26cb44b4450eae05cd59dfd0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48998 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/bpf/32: Fix Oops on tail call tests test_bpf tail call tests end up as: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: test_bpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ #195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe0 c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Call Trace: [f1b4dfe0] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee7b690 ("bpf, tests: Add load store test case for tail call") This happens because tail call is done to a BPF prog with a different stack_depth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes. This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different. Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later. Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit. With the fix, tail call tests are now successfull: test_bpf: #0 Tail call leaf jited:1 53 PASS test_bpf: #1 Tail call 2 jited:1 115 PASS test_bpf: #2 Tail call 3 jited:1 154 PASS test_bpf: #3 Tail call 4 jited:1 165 PASS test_bpf: #4 Tail call load/store leaf jited:1 101 PASS test_bpf: #5 Tail call load/store jited:1 141 PASS test_bpf: #6 Tail call error path, max count reached jited:1 994 PASS test_bpf: #7 Tail call count preserved across function calls jited:1 140975 PASS test_bpf: #8 Tail call error path, NULL target jited:1 110 PASS test_bpf: #9 Tail call error path, index out of range jited:1 69 PASS test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed] | ["https://git.kernel.org/stable/c/747a6e547240baaaf41874d27333b87b87cfd24c","https://git.kernel.org/stable/c/89d21e259a94f7d5582ec675aa445f5a79f347e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52501 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read past "commit" When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. There's barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left. The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, there's a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page. To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway. | ["https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d","https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a","https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca","https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49","https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3","https://git.kernel.org/stable/c/344f2f3e61a90f0150c754796ec9a17fcaeec03d","https://git.kernel.org/stable/c/75fc9e99b3a71006720ad1e029db11a4b5c32d4a","https://git.kernel.org/stable/c/95a404bd60af6c4d9d8db01ad14fe8957ece31ca","https://git.kernel.org/stable/c/b08a4938229dbb530a35c41b83002a1457c6ff49","https://git.kernel.org/stable/c/cee5151c5410e868826b8afecfb356f3799ebea3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52877 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Fix NULL pointer dereference in tcpm_pd_svdm() It is possible that typec_register_partner() returns ERR_PTR on failure. When port->partner is an error, a NULL pointer dereference may occur as shown below. [91222.095236][ T319] typec port0: failed to register partner (-17) ... [91225.061491][ T319] Unable to handle kernel NULL pointer dereference at virtual address 000000000000039f [91225.274642][ T319] pc : tcpm_pd_data_request+0x310/0x13fc [91225.274646][ T319] lr : tcpm_pd_data_request+0x298/0x13fc [91225.308067][ T319] Call trace: [91225.308070][ T319] tcpm_pd_data_request+0x310/0x13fc [91225.308073][ T319] tcpm_pd_rx_handler+0x100/0x9e8 [91225.355900][ T319] kthread_worker_fn+0x178/0x58c [91225.355902][ T319] kthread+0x150/0x200 [91225.355905][ T319] ret_from_fork+0x10/0x30 Add a check for port->partner to avoid dereferencing a NULL pointer. | ["https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b","https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08","https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b","https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac","https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc","https://git.kernel.org/stable/c/4987daf86c152ff882d51572d154ad12e4ff3a4b","https://git.kernel.org/stable/c/9ee038590d808a95d16adf92818dcd4752273c08","https://git.kernel.org/stable/c/b37a168c0137156042a0ca9626651b5a789e822b","https://git.kernel.org/stable/c/e5f53a68a596e04df3fde3099273435a30b6fdac","https://git.kernel.org/stable/c/e7a802447c491903aa7cb45967aa2a934a4e63fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35989 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix oops during rmmod on single-CPU platforms During the removal of the idxd driver, registered offline callback is invoked as part of the clean up process. However, on systems with only one CPU online, no valid target is available to migrate the perf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: <TASK> __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 <TASK> Fix the issue by preventing the migration of the perf context to an invalid target. | ["https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e","https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb","https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b","https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be","https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c","https://git.kernel.org/stable/c/023b6390a15a98f9c3aa5e7da78d485d5384a08e","https://git.kernel.org/stable/c/47533176fdcef17b114a6f688bc872901c1ec6bb","https://git.kernel.org/stable/c/9edd3aa34d50f27b97be30b2ba4a6af0945ff56b","https://git.kernel.org/stable/c/f221033f5c24659dc6ad7e5cf18fb1b075f4a8be","https://git.kernel.org/stable/c/f976eca36cdf94e32fa4f865db0e7c427c9aa33c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27025 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nbd: null check for nla_nest_start nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code. | ["https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d","https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e","https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced","https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8","https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797","https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983","https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a","https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf","https://git.kernel.org/stable/c/31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d","https://git.kernel.org/stable/c/44214d744be32a4769faebba764510888f1eb19e","https://git.kernel.org/stable/c/4af837db0fd3679fabc7b7758397090b0c06dced","https://git.kernel.org/stable/c/96436365e5d80d0106ea785a4f80a58e7c9edff8","https://git.kernel.org/stable/c/98e60b538e66c90b9a856828c71d4e975ebfa797","https://git.kernel.org/stable/c/b7f5aed55829f376e4f7e5ea5b80ccdcb023e983","https://git.kernel.org/stable/c/ba6a9970ce9e284cbc04099361c58731e308596a","https://git.kernel.org/stable/c/e803040b368d046434fbc8a91945c690332c4fcf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27038 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_core_get NULL dereference It is possible for clk_core_get to dereference a NULL in the following sequence: clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw() __clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core. Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL. Reading the description of this function it talks about returning NULL but that cannot be so at the moment. Update the function to check for hw before dereferencing it and return NULL if hw is NULL. | ["https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2","https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185","https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51","https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed","https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959","https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6","https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07","https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428","https://git.kernel.org/stable/c/0efb9ef6fb95384ba631d6819e66f10392aabfa2","https://git.kernel.org/stable/c/239174535dba11f7b83de0eaaa27909024f8c185","https://git.kernel.org/stable/c/6f073b24a9e2becd25ac4505a9780a87e621bb51","https://git.kernel.org/stable/c/a5d9b1aa61b401867b9066d54086b3e4ee91f8ed","https://git.kernel.org/stable/c/a8b2b26fdd011ebe36d68a9a321ca45801685959","https://git.kernel.org/stable/c/c554badcae9c45b737a22d23454170c6020b90e6","https://git.kernel.org/stable/c/d7ae7d1265686b55832a445b1db8cdd69738ac07","https://git.kernel.org/stable/c/e97fe4901e0f59a0bfd524578fe3768f8ca42428","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27388 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths. | ["https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d","https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3","https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c","https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4","https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69","https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364","https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8","https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8","https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044","https://git.kernel.org/stable/c/3cfcfc102a5e57b021b786a755a38935e357797d","https://git.kernel.org/stable/c/5e6013ae2c8d420faea553d363935f65badd32c3","https://git.kernel.org/stable/c/934212a623cbab851848b6de377eb476718c3e4c","https://git.kernel.org/stable/c/9806c2393cd2ab0a8e7bb9ffae02ce20e3112ec4","https://git.kernel.org/stable/c/996997d1fb2126feda550d6adcedcbd94911fc69","https://git.kernel.org/stable/c/b97c37978ca825557d331c9012e0c1ddc0e42364","https://git.kernel.org/stable/c/bb336cd8d5ecb69c430ebe3e7bcff68471d93fa8","https://git.kernel.org/stable/c/bfa9d86d39a0fe4685f90c3529aa9bd62a9d97a8","https://git.kernel.org/stable/c/dd292e884c649f9b1c18af0ec75ca90b390cd044","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46714 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip wbscl_set_scaler_filter if filter is null Callers can pass null in filter (i.e. from returned from the function wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is not the case. This fixes 4 NULL_RETURNS issues reported by Coverity. | ["https://git.kernel.org/stable/c/0364f1f17a86d89dc39040beea4f099e60189f1b","https://git.kernel.org/stable/c/1726914cb17cedab233820d26b86764dc08857b4","https://git.kernel.org/stable/c/54834585e91cab13e9f82d3a811deb212a4df786","https://git.kernel.org/stable/c/6d94c05a13fadd80c3e732f14c83b2632ebfaa50","https://git.kernel.org/stable/c/c083c8be6bdd046049884bec076660d4ec9a19ca","https://git.kernel.org/stable/c/c4d31653c03b90e51515b1380115d1aedad925dd","https://git.kernel.org/stable/c/e3a95f29647ae45d1ec9541cd7df64f40bf2120a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46719 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Fix null pointer dereference in trace ucsi_register_altmode checks IS_ERR for the alt pointer and treats NULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled, ucsi_register_displayport returns NULL which causes a NULL pointer dereference in trace. Rather than return NULL, call typec_port_register_altmode to register DisplayPort alternate mode as a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled. | ["https://git.kernel.org/stable/c/3aa56313b0de06ce1911950b2cc0c269614a87a9","https://git.kernel.org/stable/c/3b9f2d9301ae67070fe77a0c06758722fd7172b7","https://git.kernel.org/stable/c/7e64cabe81c303bdf6fd26b6a09a3289b33bc870","https://git.kernel.org/stable/c/8095bf0579ed4906a33f7bec675bfb29b6b16a3b","https://git.kernel.org/stable/c/99331fe68a8eaa4097143a33fb0c12d5e5e8e830","https://git.kernel.org/stable/c/99516f76db48e1a9d54cdfed63c1babcee4e71a5","https://git.kernel.org/stable/c/b4243c05d7e3db0bdbf9124e6fa59b4ca7c807ae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce. | ["https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e","https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026","https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63","https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192","https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534","https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753","https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e","https://git.kernel.org/stable/c/270475d6d2410ec66e971bf181afe1958dad565e","https://git.kernel.org/stable/c/6bfc5377a210dbda2a237f16d94d1bd4f1335026","https://git.kernel.org/stable/c/7403f4118ab94be837ab9d770507537a8057bc63","https://git.kernel.org/stable/c/8d9ac1b6665c73f23e963775f85d99679fd8e192","https://git.kernel.org/stable/c/971e5dadffd02beba1063e7dd9c3a82de17cf534","https://git.kernel.org/stable/c/c132f2ba716b5ee6b35f82226a6e5417d013d753","https://git.kernel.org/stable/c/d4d975e7921079f877f828099bb8260af335508f","https://git.kernel.org/stable/c/ddbd89deb7d32b1fbb879f48d68fda1a8ac58e8e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26826 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix data re-injection from stale subflow When the MPTCP PM detects that a subflow is stale, all the packet scheduler must re-inject all the mptcp-level unacked data. To avoid acquiring unneeded locks, it first try to check if any unacked data is present at all in the RTX queue, but such check is currently broken, as it uses TCP-specific helper on an MPTCP socket. Funnily enough fuzzers and static checkers are happy, as the accessed memory still belongs to the mptcp_sock struct, and even from a functional perspective the recovery completed successfully, as the short-cut test always failed. A recent unrelated TCP change - commit d5fed5addb2b ("tcp: reorganize tcp_sock fast path variables") - exposed the issue, as the tcp field reorganization makes the mptcp code always skip the re-inection. Fix the issue dropping the bogus call: we are on a slow path, the early optimization proved once again to be evil. | ["https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8","https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8","https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2","https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5","https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598","https://git.kernel.org/stable/c/624902eab7abcb8731b333ec73f206d38d839cd8","https://git.kernel.org/stable/c/6673d9f1c2cd984390550dbdf7d5ae07b20abbf8","https://git.kernel.org/stable/c/6f95120f898b40d13fd441225ef511307853c9c2","https://git.kernel.org/stable/c/b609c783c535493aa3fca22c7e40a120370b1ca5","https://git.kernel.org/stable/c/b6c620dc43ccb4e802894e54b651cf81495e9598"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38780 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma-buf/sw-sync: don't enable IRQ from sync_print_obj() Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore from known context") by error replaced spin_unlock_irqrestore() with spin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despite sync_print_obj() is called from sync_debugfs_show(), lockdep complains inconsistent lock state warning. Use plain spin_{lock,unlock}() for sync_print_obj(), for sync_debugfs_show() is already using spin_{lock,unlock}_irq(). | ["https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed","https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a","https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a","https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e","https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878","https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef","https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8","https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39","https://git.kernel.org/stable/c/165b25e3ee9333f7b04f8db43895beacb51582ed","https://git.kernel.org/stable/c/1ff116f68560a25656933d5a18e7619cb6773d8a","https://git.kernel.org/stable/c/242b30466879e6defa521573c27e12018276c33a","https://git.kernel.org/stable/c/8a283cdfc8beeb14024387a925247b563d614e1e","https://git.kernel.org/stable/c/9d75fab2c14a25553a1664586ed122c316bd1878","https://git.kernel.org/stable/c/a4ee78244445ab73af22bfc5a5fc543963b25aef","https://git.kernel.org/stable/c/ae6fc4e6a3322f6d1c8ff59150d8469487a73dd8","https://git.kernel.org/stable/c/b794918961516f667b0c745aebdfebbb8a98df39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40980 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drop_monitor: replace spin_lock by raw_spin_lock trace_drop_common() is called with preemption disabled, and it acquires a spin_lock. This is problematic for RT kernels because spin_locks are sleeping locks in this configuration, which causes the following splat: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47 preempt_count: 1, expected: 0 RCU nest depth: 2, expected: 2 5 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290 irq event stamp: 139909 hardirqs last enabled at (139908): [<ffffffffb1df2b33>] _raw_spin_unlock_irqrestore+0x63/0x80 hardirqs last disabled at (139909): [<ffffffffb19bd03d>] trace_drop_common.constprop.0+0x26d/0x290 softirqs last enabled at (139892): [<ffffffffb07a1083>] __local_bh_enable_ip+0x103/0x170 softirqs last disabled at (139898): [<ffffffffb0909b33>] rcu_cpu_kthread+0x93/0x1f0 Preemption disabled at: [<ffffffffb1de786b>] rt_mutex_slowunlock+0xab/0x2e0 CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7 Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520 ... trace_drop_common() also disables interrupts, but this is a minor issue because we could easily replace it with a local_lock. Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic context. | ["https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e","https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334","https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0","https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5","https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac","https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195","https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3","https://git.kernel.org/stable/c/07ea878684dfb78a9d4f564c39d07e855a9e242e","https://git.kernel.org/stable/c/594e47957f3fe034645e6885393ce96c12286334","https://git.kernel.org/stable/c/76ce2f9125244e1708d29c1d3f9d1d50b347bda0","https://git.kernel.org/stable/c/96941f29ebcc1e9cbf570dc903f30374909562f5","https://git.kernel.org/stable/c/b3722fb69468693555f531cddda5c30444726dac","https://git.kernel.org/stable/c/f1e197a665c2148ebc25fe09c53689e60afea195","https://git.kernel.org/stable/c/f251ccef1d864790e5253386e95544420b7cd8f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40981 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bypass empty buckets in batadv_purge_orig_ref() Many syzbot reports are pointing to soft lockups in batadv_purge_orig_ref() [1] Root cause is unknown, but we can avoid spending too much time there and perhaps get more interesting reports. [1] watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621] Modules linked in: irq event stamp: 6182794 hardirqs last enabled at (6182793): [<ffff8000801dae10>] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [<ffff80008ad66a78>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [<ffff80008ad66a78>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [<ffff80008aab71c4>] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [<ffff80008aab71c4>] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [<ffff80008aab61dc>] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [<ffff80008aab61dc>] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271 CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 Workqueue: bat_events batadv_purge_orig pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 sp : ffff800099007970 x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000 x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001 x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4 x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0 x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001 x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000 Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103 sp : ffff800093a17d30 x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4 x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002 x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000 x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396 x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001 ---truncated--- | ["https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2","https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8","https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0","https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11","https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030","https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07","https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a","https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16","https://git.kernel.org/stable/c/154e3f862ba33675cf3f4abf0a0a309a89df87d2","https://git.kernel.org/stable/c/2685008a5f9a636434a8508419cee8158a2f52c8","https://git.kernel.org/stable/c/40dc8ab605894acae1473e434944924a22cfaaa0","https://git.kernel.org/stable/c/79636f636126775436a11ee9cf00a9253a33ac11","https://git.kernel.org/stable/c/82cdea8f3af1e36543c937df963d108c60bea030","https://git.kernel.org/stable/c/92176caf9896572f00e741a93cecc0ef1172da07","https://git.kernel.org/stable/c/ae7f3cffe86aea3da0e8e079525a1ae619b8862a","https://git.kernel.org/stable/c/fed7914858a1f1f3e6350bb0f620d6ef15107d16"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41063 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: cancel all works upon hci_unregister_dev() syzbot is reporting that calling hci_release_dev() from hci_error_reset() due to hci_dev_put() from hci_error_reset() can cause deadlock at destroy_workqueue(), for hci_error_reset() is called from hdev->req_workqueue which destroy_workqueue() needs to flush. We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are queued into hdev->workqueue and hdev->{power_on,error_reset} which are queued into hdev->req_workqueue are no longer running by the moment destroy_workqueue(hdev->workqueue); destroy_workqueue(hdev->req_workqueue); are called from hci_release_dev(). Call cancel_work_sync() on these work items from hci_unregister_dev() as soon as hdev->list is removed from hci_dev_list. | ["https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913","https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678","https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9","https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa","https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed","https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f","https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39","https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92","https://git.kernel.org/stable/c/0d151a103775dd9645c78c97f77d6e2a5298d913","https://git.kernel.org/stable/c/3f939bd73fed12dddc2a32a76116c19ca47c7678","https://git.kernel.org/stable/c/48542881997e17b49dc16b93fe910e0cfcf7a9f9","https://git.kernel.org/stable/c/96600c2e5ee8213dbab5df1617293d8e847bb4fa","https://git.kernel.org/stable/c/9cfc84b1d464cc024286f42a090718f9067b80ed","https://git.kernel.org/stable/c/d2ce562a5aff1dcd0c50d9808ea825ef90da909f","https://git.kernel.org/stable/c/d6cbce18370641a21dd889e8613d8153df15eb39","https://git.kernel.org/stable/c/ddeda6ca5f218b668b560d90fc31ae469adbfd92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42153 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether. | ["https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289","https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2","https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176","https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f","https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3","https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6","https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af","https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e","https://git.kernel.org/stable/c/27cd3873fa76ebeb9f948baae40cb9a6d8692289","https://git.kernel.org/stable/c/2849a1b747cf37aa5b684527104d3a53f1e296d2","https://git.kernel.org/stable/c/3503372d0bf7b324ec0bd6b90606703991426176","https://git.kernel.org/stable/c/3d32327f5cfc087ee3922a3bcdcc29880dcdb50f","https://git.kernel.org/stable/c/92e494a7568b60ae80d57fc0deafcaf3a4029ab3","https://git.kernel.org/stable/c/a349e5ab4dc9954746e836cd10b407ce48f9b2f6","https://git.kernel.org/stable/c/effe0500afda017a86c94482b1e36bc37586c9af","https://git.kernel.org/stable/c/f63b94be6942ba82c55343e196bd09b53227618e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48972 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add() Kernel fault injection test reports null-ptr-deref as follows: BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace: <TASK> raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87 call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944 unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982 unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879 register_netdevice+0x9a8/0xb90 net/core/dev.c:10083 ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659 ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229 mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316 ieee802154_if_add() allocates wpan_dev as netdev's private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref. Use INIT_LIST_HEAD() on it to initialize it correctly. | ["https://git.kernel.org/stable/c/1831d4540406708e48239cf38fd9c3b7ea98e08f","https://git.kernel.org/stable/c/42c319635c0cf7eb36eccac6cda76532f47b61a3","https://git.kernel.org/stable/c/623918f40fa68e3bb21312a3fafb90f491bf5358","https://git.kernel.org/stable/c/7410f4d1221bb182510b7778ab6eefa8b9b7102d","https://git.kernel.org/stable/c/9980a3ea20de40c83817877106c909cb032692d2","https://git.kernel.org/stable/c/a110287ef4a423980309490df632e1c1e73b3dc9","https://git.kernel.org/stable/c/b3d72d3135d2ef68296c1ee174436efd65386f04","https://git.kernel.org/stable/c/f00c84fb1635c27ba24ec5df65d5bd7d7dc00008"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49002 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init() for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak. | ["https://git.kernel.org/stable/c/2a8f7b90681472948de172dbbf5a54cd342870aa","https://git.kernel.org/stable/c/4bedbbd782ebbe7287231fea862c158d4f08a9e3","https://git.kernel.org/stable/c/71c4a621985fc051ab86d3a86c749069a993fcb2","https://git.kernel.org/stable/c/876d7bfb89273997056220029ff12b1c2cc4691d","https://git.kernel.org/stable/c/a5c65cd56aed027f8a97fda8b691caaeb66d115e","https://git.kernel.org/stable/c/bdb613ef179ad4bb9d56a2533e9b30e434f1dfb7","https://git.kernel.org/stable/c/cbdd83bd2fd67142b03ce9dbdd1eab322ff7321f","https://git.kernel.org/stable/c/d47bc9d7bcdbb9adc9703513d964b514fee5b0bf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50061 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove. | ["https://git.kernel.org/stable/c/2a21bad9964c91b34d65ba269914233720c0b1ce","https://git.kernel.org/stable/c/609366e7a06d035990df78f1562291c3bf0d4a12","https://git.kernel.org/stable/c/687016d6a1efbfacdd2af913e2108de6b75a28d5","https://git.kernel.org/stable/c/ea0256e393e0072e8c80fd941547807f0c28108b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50086 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used. | ["https://git.kernel.org/stable/c/0f62358ce85b2d4c949ef1b648be01b29cec667a","https://git.kernel.org/stable/c/5511999e9615e4318e9142d23b29bd1597befc08","https://git.kernel.org/stable/c/7aa8804c0b67b3cb263a472d17f2cb50d7f1a930","https://git.kernel.org/stable/c/a9839c37fd813b432988f58a9d9dd59253d3eb2c","https://git.kernel.org/stable/c/ee371898b53a9b9b51c02d22a8c31bfb86d45f0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Fix GEM handle creation UAF Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. | ["https://git.kernel.org/stable/c/011ecdbcd520c90c344b872ca6b4821f7783b2f8","https://git.kernel.org/stable/c/19ec87d06acfab2313ee82b2a689bf0c154e57ea","https://git.kernel.org/stable/c/52531258318ed59a2dc5a43df2eaf0eb1d65438e","https://git.kernel.org/stable/c/68bcd063857075d2f9edfed6024387ac377923e2","https://git.kernel.org/stable/c/adc48e5e408afbb01d261bd303fd9fbbbaa3e317","https://git.kernel.org/stable/c/d01d6d2b06c0d8390adf8f3ba08aa60b5642ef73"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3239 | High | fixed |
|
A flaw use after free in the Linux kernel video4linux driver was found in the way user triggers em28xx_usb_probe() for the Empia 28xx based TV cards. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d","https://security.netapp.com/advisory/ntap-20230214-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c08eadca1bdfa099e20a32f8fa4b52b2f672236d","https://security.netapp.com/advisory/ntap-20230214-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49960 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd. | ["https://git.kernel.org/stable/c/0ce160c5bdb67081a62293028dc85758a8efb22a","https://git.kernel.org/stable/c/22e9b83f0f33bc5a7a3181769d1dccbf021f5b04","https://git.kernel.org/stable/c/7aac0c17a8cdf4a3236991c1e60435c6a984076c","https://git.kernel.org/stable/c/9203817ba46ebba7c865c8de2aba399537b6e891","https://git.kernel.org/stable/c/b85569585d0154d4db1e4f9e3e6a4731d407feb0","https://git.kernel.org/stable/c/cf3196e5e2f36cd80dab91ffae402e13935724bc","https://git.kernel.org/stable/c/fa78fb51d396f4f2f80f8e96a3b1516f394258be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49989 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] <TASK> [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] </TASK> | ["https://git.kernel.org/stable/c/20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d","https://git.kernel.org/stable/c/3c0ff4de45ce2c5f7997a1ffa6eefee4b79e6b58","https://git.kernel.org/stable/c/43c296870740a3a264cdca9f18db12e12e9cfbdb","https://git.kernel.org/stable/c/7af9e6fa63dbd43a61d4ecc8f59426596a75e507","https://git.kernel.org/stable/c/cf6f3ebd6312d465fee096d1f58089b177c7c67f","https://git.kernel.org/stable/c/df948b5ba6858d5da34f622d408e5517057cec07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50047 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in async decryption Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API. Reproducer: # mount.cifs -o ...,seal,esize=1 //srv/share /mnt # dd if=/mnt/largefile of=/dev/null ... [ 194.196391] ================================================================== [ 194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110 [ 194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899 [ 194.197707] [ 194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43 [ 194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 [ 194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs] [ 194.200032] Call Trace: [ 194.200191] <TASK> [ 194.200327] dump_stack_lvl+0x4e/0x70 [ 194.200558] ? gf128mul_4k_lle+0xc1/0x110 [ 194.200809] print_report+0x174/0x505 [ 194.201040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 194.201352] ? srso_return_thunk+0x5/0x5f [ 194.201604] ? __virt_addr_valid+0xdf/0x1c0 [ 194.201868] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202128] kasan_report+0xc8/0x150 [ 194.202361] ? gf128mul_4k_lle+0xc1/0x110 [ 194.202616] gf128mul_4k_lle+0xc1/0x110 [ 194.202863] ghash_update+0x184/0x210 [ 194.203103] shash_ahash_update+0x184/0x2a0 [ 194.203377] ? __pfx_shash_ahash_update+0x10/0x10 [ 194.203651] ? srso_return_thunk+0x5/0x5f [ 194.203877] ? crypto_gcm_init_common+0x1ba/0x340 [ 194.204142] gcm_hash_assoc_remain_continue+0x10a/0x140 [ 194.204434] crypt_message+0xec1/0x10a0 [cifs] [ 194.206489] ? __pfx_crypt_message+0x10/0x10 [cifs] [ 194.208507] ? srso_return_thunk+0x5/0x5f [ 194.209205] ? srso_return_thunk+0x5/0x5f [ 194.209925] ? srso_return_thunk+0x5/0x5f [ 194.210443] ? srso_return_thunk+0x5/0x5f [ 194.211037] decrypt_raw_data+0x15f/0x250 [cifs] [ 194.212906] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] [ 194.214670] ? srso_return_thunk+0x5/0x5f [ 194.215193] smb2_decrypt_offload+0x12a/0x6c0 [cifs] This is because TFM is being used in parallel. Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()). Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it's always going to be a synchronous operation. | ["https://git.kernel.org/stable/c/0809fb86ad13b29e1d6d491364fc7ea4fb545995","https://git.kernel.org/stable/c/538c26d9bf70c90edc460d18c81008a4e555925a","https://git.kernel.org/stable/c/8f14a476abba13144df5434871a7225fd29af633","https://git.kernel.org/stable/c/b0abcd65ec545701b8793e12bc27dc98042b151a","https://git.kernel.org/stable/c/bce966530fd5542bbb422cb45ecb775f7a1a6bc3","https://git.kernel.org/stable/c/ef51c0d544b1518b35364480317ab6d3468f205d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21680 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pktgen: Avoid out-of-bounds access in get_imix_entries Passing a sufficient amount of imix entries leads to invalid access to the pkt_dev->imix_entries array because of the incorrect boundary check. UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imix_pkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl lib/dump_stack.c:117 __ubsan_handle_out_of_bounds lib/ubsan.c:429 get_imix_entries net/core/pktgen.c:874 pktgen_if_write net/core/pktgen.c:1063 pde_write fs/proc/inode.c:334 proc_reg_write fs/proc/inode.c:346 vfs_write fs/read_write.c:593 ksys_write fs/read_write.c:644 do_syscall_64 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:130 Found by Linux Verification Center (linuxtesting.org) with SVACE. [ fp: allow to fill the array completely; minor changelog cleanup ] | ["https://git.kernel.org/stable/c/1a9b65c672ca9dc4ba52ca2fd54329db9580ce29","https://git.kernel.org/stable/c/3450092cc2d1c311c5ea92a2486daa2a33520ea5","https://git.kernel.org/stable/c/76201b5979768500bca362871db66d77cb4c225e","https://git.kernel.org/stable/c/7cde21f52042aa2e29a654458166b873d2ae66b3","https://git.kernel.org/stable/c/e5d24a7074dcd0c7e76b7e7e4efbbe7418d62486"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49991 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug. | ["https://git.kernel.org/stable/c/30ceb873cc2e97348d9da2265b2d1ddf07f682e1","https://git.kernel.org/stable/c/6c9289806591807e4e3be9a23df8ee2069180055","https://git.kernel.org/stable/c/71f3240f82987f0f070ea5bed559033de7d4c0e1","https://git.kernel.org/stable/c/c86ad39140bbcb9dc75a10046c2221f657e8083b","https://git.kernel.org/stable/c/e7831613cbbcd9058d3658fbcdc5d5884ceb2e0c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53061 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment. | ["https://git.kernel.org/stable/c/14a22762c3daeac59a5a534e124acbb4d7a79b3a","https://git.kernel.org/stable/c/784bc785a453eb2f8433dd62075befdfa1b2d6fd","https://git.kernel.org/stable/c/a930cddfd153b5d4401df0c01effa14c831ff21e","https://git.kernel.org/stable/c/c5f6fefcda8fac8f082b6c5bf416567f4e100c51","https://git.kernel.org/stable/c/c85db2d4432de4ff9d97006691ce2dcb5bda660e","https://git.kernel.org/stable/c/c951a0859fdacf49a2298b5551a7e52b95ff6f51","https://git.kernel.org/stable/c/e5117f6e7adcf9fd7546cdd0edc9abe4474bc98b","https://git.kernel.org/stable/c/f54e8e1e39dacccebcfb9a9a36f0552a0a97e2ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48954 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/qeth: fix use-after-free in hsci KASAN found that addr was dereferenced after br2dev_event_work was freed. ================================================================== BUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000_event qeth_l2_br2dev_worker Call Trace: [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8 [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0 [<000000016942d118>] print_report+0x110/0x1f8 [<0000000167a7bd04>] kasan_report+0xfc/0x128 [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0 [<00000001673edd1e>] process_one_work+0x76e/0x1128 [<00000001673ee85c>] worker_thread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] __ret_from_fork+0x8a/0xe8 [<00000001694711da>] ret_from_fork+0xa/0x40 Allocated by task 108338: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 __kasan_kmalloc+0xa0/0xc0 qeth_l2_switchdev_event+0x25a/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Freed by task 540: kasan_save_stack+0x40/0x68 kasan_set_track+0x36/0x48 kasan_save_free_info+0x4c/0x68 ____kasan_slab_free+0x14e/0x1a8 __kasan_slab_free+0x24/0x30 __kmem_cache_free+0x168/0x338 qeth_l2_br2dev_worker+0x154/0x6b0 process_one_work+0x76e/0x1128 worker_thread+0x184/0x1098 kthread+0x26a/0x310 __ret_from_fork+0x8a/0xe8 ret_from_fork+0xa/0x40 Last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 insert_work+0x56/0x2e8 __queue_work+0x4ce/0xd10 queue_work_on+0xf4/0x100 qeth_l2_switchdev_event+0x520/0x738 atomic_notifier_call_chain+0x9c/0xf8 br_switchdev_fdb_notify+0xf4/0x110 fdb_notify+0x122/0x180 fdb_add_entry.constprop.0.isra.0+0x312/0x558 br_fdb_add+0x59e/0x858 rtnl_fdb_add+0x58a/0x928 rtnetlink_rcv_msg+0x5f8/0x8d8 netlink_rcv_skb+0x1f2/0x408 netlink_unicast+0x570/0x790 netlink_sendmsg+0x752/0xbe0 sock_sendmsg+0xca/0x110 ____sys_sendmsg+0x510/0x6a8 ___sys_sendmsg+0x12a/0x180 __sys_sendmsg+0xe6/0x168 __do_sys_socketcall+0x3c8/0x468 do_syscall+0x22c/0x328 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 Second to last potentially related work creation: kasan_save_stack+0x40/0x68 __kasan_record_aux_stack+0xbe/0xd0 kvfree_call_rcu+0xb2/0x760 kernfs_unlink_open_file+0x348/0x430 kernfs_fop_release+0xc2/0x320 __fput+0x1ae/0x768 task_work_run+0x1bc/0x298 exit_to_user_mode_prepare+0x1a0/0x1a8 __do_syscall+0x94/0xf0 system_call+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated--- | ["https://git.kernel.org/stable/c/bde0dfc7c4569406a6ddeec363d04a1df7b3073f","https://git.kernel.org/stable/c/db6343a5b0d9661f2dd76f653c6d274d38234d2b","https://git.kernel.org/stable/c/ebaaadc332cd21e9df4dcf9ce12552d9354bbbe4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46828 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched: sch_cake: fix bulk flow accounting logic for host fairness In sch_cake, we keep track of the count of active bulk flows per host, when running in dst/src host fairness mode, which is used as the round-robin weight when iterating through flows. The count of active bulk flows is updated whenever a flow changes state. This has a peculiar interaction with the hash collision handling: when a hash collision occurs (after the set-associative hashing), the state of the hash bucket is simply updated to match the new packet that collided, and if host fairness is enabled, that also means assigning new per-host state to the flow. For this reason, the bulk flow counters of the host(s) assigned to the flow are decremented, before new state is assigned (and the counters, which may not belong to the same host anymore, are incremented again). Back when this code was introduced, the host fairness mode was always enabled, so the decrement was unconditional. When the configuration flags were introduced the *increment* was made conditional, but the *decrement* was not. Which of course can lead to a spurious decrement (and associated wrap-around to U16_MAX). AFAICT, when host fairness is disabled, the decrement and wrap-around happens as soon as a hash collision occurs (which is not that common in itself, due to the set-associative hashing). However, in most cases this is harmless, as the value is only used when host fairness mode is enabled. So in order to trigger an array overflow, sch_cake has to first be configured with host fairness disabled, and while running in this mode, a hash collision has to occur to cause the overflow. Then, the qdisc has to be reconfigured to enable host fairness, which leads to the array out-of-bounds because the wrapped-around value is retained and used as an array index. It seems that syzbot managed to trigger this, which is quite impressive in its own right. This patch fixes the issue by introducing the same conditional check on decrement as is used on increment. The original bug predates the upstreaming of cake, but the commit listed in the Fixes tag touched that code, meaning that this patch won't apply before that. | ["https://git.kernel.org/stable/c/4a4eeefa514db570be025ab46d779af180e2c9bb","https://git.kernel.org/stable/c/546ea84d07e3e324644025e2aae2d12ea4c5896e","https://git.kernel.org/stable/c/549e407569e08459d16122341d332cb508024094","https://git.kernel.org/stable/c/7725152b54d295b7da5e34c2f419539b30d017bd","https://git.kernel.org/stable/c/cde71a5677971f4f1b69b25e854891dbe78066a4","https://git.kernel.org/stable/c/d4a9039a7b3d8005b90c7b1a55a306444f0e5447","https://git.kernel.org/stable/c/d7c01c0714c04431b5e18cf17a9ea68a553d1c3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49287 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tpm: fix reference counting for struct tpm_chip The following sequence of operations results in a refcount warning: 1. Open device /dev/tpmrm. 2. Remove module tpm_tis_spi. 3. Write a TPM command to the file descriptor opened at step 1. ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1161 at lib/refcount.c:25 kobject_get+0xa0/0xa4 refcount_t: addition on 0; use-after-free. Modules linked in: tpm_tis_spi tpm_tis_core tpm mdio_bcm_unimac brcmfmac sha256_generic libsha256 sha256_arm hci_uart btbcm bluetooth cfg80211 vc4 brcmutil ecdh_generic ecc snd_soc_core crc32_arm_ce libaes raspberrypi_hwmon ac97_bus snd_pcm_dmaengine bcm2711_thermal snd_pcm snd_timer genet snd phy_generic soundcore [last unloaded: spi_bcm2835] CPU: 3 PID: 1161 Comm: hold_open Not tainted 5.10.0ls-main-dirty #2 Hardware name: BCM2711 [<c0410c3c>] (unwind_backtrace) from [<c040b580>] (show_stack+0x10/0x14) [<c040b580>] (show_stack) from [<c1092174>] (dump_stack+0xc4/0xd8) [<c1092174>] (dump_stack) from [<c0445a30>] (__warn+0x104/0x108) [<c0445a30>] (__warn) from [<c0445aa8>] (warn_slowpath_fmt+0x74/0xb8) [<c0445aa8>] (warn_slowpath_fmt) from [<c08435d0>] (kobject_get+0xa0/0xa4) [<c08435d0>] (kobject_get) from [<bf0a715c>] (tpm_try_get_ops+0x14/0x54 [tpm]) [<bf0a715c>] (tpm_try_get_ops [tpm]) from [<bf0a7d6c>] (tpm_common_write+0x38/0x60 [tpm]) [<bf0a7d6c>] (tpm_common_write [tpm]) from [<c05a7ac0>] (vfs_write+0xc4/0x3c0) [<c05a7ac0>] (vfs_write) from [<c05a7ee4>] (ksys_write+0x58/0xcc) [<c05a7ee4>] (ksys_write) from [<c04001a0>] (ret_fast_syscall+0x0/0x4c) Exception stack(0xc226bfa8 to 0xc226bff0) bfa0: 00000000 000105b4 00000003 beafe664 00000014 00000000 bfc0: 00000000 000105b4 000103f8 00000004 00000000 00000000 b6f9c000 beafe684 bfe0: 0000006c beafe648 0001056c b6eb6944 ---[ end trace d4b8409def9b8b1f ]--- The reason for this warning is the attempt to get the chip->dev reference in tpm_common_write() although the reference counter is already zero. Since commit 8979b02aaf1d ("tpm: Fix reference count to main device") the extra reference used to prevent a premature zero counter is never taken, because the required TPM_CHIP_FLAG_TPM2 flag is never set. Fix this by moving the TPM 2 character device handling from tpm_chip_alloc() to tpm_add_char_device() which is called at a later point in time when the flag has been set in case of TPM2. Commit fdc915f7f719 ("tpm: expose spaces via a device link /dev/tpmrm<n>") already introduced function tpm_devs_release() to release the extra reference but did not implement the required put on chip->devs that results in the call of this function. Fix this by putting chip->devs in tpm_chip_unregister(). Finally move the new implementation for the TPM 2 handling into a new function to avoid multiple checks for the TPM_CHIP_FLAG_TPM2 flag in the good case and error cases. | ["https://git.kernel.org/stable/c/290e05f346d1829e849662c97e42d5ad984f5258","https://git.kernel.org/stable/c/2f928c0d5c02dbab49e8c19d98725c822f6fc409","https://git.kernel.org/stable/c/473a66f99cb8173c14138c5a5c69bfad04e8f9ac","https://git.kernel.org/stable/c/662893b4f6bd466ff9e1cd454c44c26d32d554fe","https://git.kernel.org/stable/c/6e7baf84149fb43950631415de231b3a41915aa3","https://git.kernel.org/stable/c/7e0438f83dc769465ee663bb5dcf8cc154940712","https://git.kernel.org/stable/c/a27ed2f3695baf15f9b34d2d7a1f9fc105539a81","https://git.kernel.org/stable/c/cb64bd038beacb4331fe464a36c8b5481e8f51e2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56786 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: put bpf_link's program when link is safe to be deallocated In general, BPF link's underlying BPF program should be considered to be reachable through attach hook -> link -> prog chain, and, pessimistically, we have to assume that as long as link's memory is not safe to free, attach hook's code might hold a pointer to BPF program and use it. As such, it's not (generally) correct to put link's program early before waiting for RCU GPs to go through. More eager bpf_prog_put() that we currently do is mostly correct due to BPF program's release code doing similar RCU GP waiting, but as will be shown in the following patches, BPF program can be non-sleepable (and, thus, reliant on only "classic" RCU GP), while BPF link's attach hook can have sleepable semantics and needs to be protected by RCU Tasks Trace, and for such cases BPF link has to go through RCU Tasks Trace + "classic" RCU GPs before being deallocated. And so, if we put BPF program early, we might free BPF program before we free BPF link, leading to use-after-free situation. So, this patch defers bpf_prog_put() until we are ready to perform bpf_link's deallocation. At worst, this delays BPF program freeing by one extra RCU GP, but that seems completely acceptable. Alternatively, we'd need more elaborate ways to determine BPF hook, BPF link, and BPF program lifetimes, and how they relate to each other, which seems like an unnecessary complication. Note, for most BPF links we still will perform eager bpf_prog_put() and link dealloc, so for those BPF links there are no observable changes whatsoever. Only BPF links that use deferred dealloc might notice slightly delayed freeing of BPF programs. Also, to reduce code and logic duplication, extract program put + link dealloc logic into bpf_link_dealloc() helper. | ["https://git.kernel.org/stable/c/2fcb921c2799c49ac5e365cf4110f94a64ae4885","https://git.kernel.org/stable/c/5fe23c57abadfd46a7a66e81f3536e4757252a0b","https://git.kernel.org/stable/c/f44ec8733a8469143fde1984b5e6931b2e2f6f3f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42230 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix scv instruction crash with kexec kexec on pseries disables AIL (reloc_on_exc), required for scv instruction support, before other CPUs have been shut down. This means they can execute scv instructions after AIL is disabled, which causes an interrupt at an unexpected entry location that crashes the kernel. Change the kexec sequence to disable AIL after other CPUs have been brought down. As a refresher, the real-mode scv interrupt vector is 0x17000, and the fixed-location head code probably couldn't easily deal with implementing such high addresses so it was just decided not to support that interrupt at all. | ["https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011","https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3","https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c","https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5","https://git.kernel.org/stable/c/21a741eb75f80397e5f7d3739e24d7d75e619011","https://git.kernel.org/stable/c/8c6506616386ce37e59b2745fc481c6713fae4f3","https://git.kernel.org/stable/c/c550679d604798d9fed8a5b2bb5693448a25407c","https://git.kernel.org/stable/c/d10e3c39001e9194b9a1bfd6979bd3fa19dccdc5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52800 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix htt pktlog locking The ath11k active pdevs are protected by RCU but the htt pktlog handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a read-side critical section. Mark the code in question as an RCU read-side critical section to avoid any potential use-after-free issues. Compile tested only. | ["https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679","https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e","https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d","https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8","https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c","https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961","https://git.kernel.org/stable/c/03ed26935bebf6b6fd8a656490bf3dcc71b72679","https://git.kernel.org/stable/c/3a51e6b4da71fdfa43ec006d6abc020f3e22d14e","https://git.kernel.org/stable/c/3f77c7d605b29df277d77e9ee75d96e7ad145d2d","https://git.kernel.org/stable/c/423762f021825b5e57c3d6f01ff96a9ff19cdcd8","https://git.kernel.org/stable/c/69cede2a5a5f60e3f5602b901b52cb64edd2ea6c","https://git.kernel.org/stable/c/e3199b3fac65c9f103055390b6fd07c5cffa5961"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38550 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: kirkwood: Fix potential NULL dereference In kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL if CONFIG_PLAT_ORION macro is not defined. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c","https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6","https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6","https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169","https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489","https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50","https://git.kernel.org/stable/c/1a7254525ca7a6f3e37d7882d7f7ad97f6235f7c","https://git.kernel.org/stable/c/5bf5154739cd676b6d0958079070557c8d96afb6","https://git.kernel.org/stable/c/802b49e39da669b54bd9b77dc3c649999a446bf6","https://git.kernel.org/stable/c/d48d0c5fd733bd6d8d3ddb2ed553777ab4724169","https://git.kernel.org/stable/c/de9987cec6fde1dd41dfcb971433e05945852489","https://git.kernel.org/stable/c/ea60ab95723f5738e7737b56dda95e6feefa5b50"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-40476 | Medium | fixed |
|
A null pointer dereference issue was discovered in fs/io_uring.c in the Linux kernel before 5.15.62. A local user could use this flaw to crash the system or potentially cause a denial of service. | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.15.61\u0026id=3746d62ecf1c872a520c4866118edccb121c44fd","https://lore.kernel.org/lkml/CAO4S-mdVW5GkODk0+vbQexNAAJZopwzFJ9ACvRCJ989fQ4A6Ow%40mail.gmail.com/","https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.62","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/io_uring.c?h=v5.15.61\u0026id=3746d62ecf1c872a520c4866118edccb121c44fd","https://lore.kernel.org/lkml/CAO4S-mdVW5GkODk0+vbQexNAAJZopwzFJ9ACvRCJ989fQ4A6Ow%40mail.gmail.com/","https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38608 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix netif state handling mlx5e_suspend cleans resources only if netif_device_present() returns true. However, mlx5e_resume changes the state of netif, via mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks: mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason. ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :( Hence, clean resources in this case as well. [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace: <TASK> ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644","https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6","https://git.kernel.org/stable/c/3d5918477f94e4c2f064567875c475468e264644","https://git.kernel.org/stable/c/f7e6cfb864a53af71c5cc904f1cc22215d68f5c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48661 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: mockup: Fix potential resource leakage when register a chip If creation of software node fails, the locally allocated string array is left unfreed. Free it on error path. | ["https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933","https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872","https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790","https://git.kernel.org/stable/c/02743c4091ccfb246f5cdbbe3f44b152d5d12933","https://git.kernel.org/stable/c/41f857033c44442a27f591fda8d986e7c9e42872","https://git.kernel.org/stable/c/9b26723e058faaf11b532fb4aa16d6849d581790"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48859 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr This node pointer is returned by of_find_compatible_node() with refcount incremented. Calling of_node_put() to aovid the refcount leak. | ["https://git.kernel.org/stable/c/4cc66bf17220ff9631f9fa99b02a872e0ad5a08b","https://git.kernel.org/stable/c/b7c2fd1d126329340639adfb8dd2938fe4b65df7","https://git.kernel.org/stable/c/c9ffa3e2bc451816ce0295e40063514fabf2bd36","https://git.kernel.org/stable/c/4cc66bf17220ff9631f9fa99b02a872e0ad5a08b","https://git.kernel.org/stable/c/b7c2fd1d126329340639adfb8dd2938fe4b65df7","https://git.kernel.org/stable/c/c9ffa3e2bc451816ce0295e40063514fabf2bd36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57940 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: exfat: fix the infinite loop in exfat_readdir() If the file system is corrupted so that a cluster is linked to itself in the cluster chain, and there is an unused directory entry in the cluster, 'dentry' will not be incremented, causing condition 'dentry < max_dentries' unable to prevent an infinite loop. This infinite loop causes s_lock not to be released, and other tasks will hang, such as exfat_sync_fs(). This commit stops traversing the cluster chain when there is unused directory entry in the cluster to avoid this infinite loop. | ["https://git.kernel.org/stable/c/28c21f0ac5293a4bf19b3e0e32005d6dd31a6c17","https://git.kernel.org/stable/c/31beabd0f47f8c3ed9965ba861c9e5b252d4920a","https://git.kernel.org/stable/c/d8cfbb8723bd3d3222f360227a1cc15227189ca6","https://git.kernel.org/stable/c/d9ea94f5cd117d56e573696d0045ab3044185a15","https://git.kernel.org/stable/c/dc1d7afceb982e8f666e70a582e6b5aa806de063","https://git.kernel.org/stable/c/fee873761bd978d077d8c55334b4966ac4cb7b59"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21638 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: auth_enable: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure. | ["https://git.kernel.org/stable/c/15649fd5415eda664ef35780c2013adeb5d9c695","https://git.kernel.org/stable/c/1b67030d39f2b00f94ac1f0af11ba6657589e4d3","https://git.kernel.org/stable/c/7ec30c54f339c640aa7e49d7e9f7bbed6bd42bf6","https://git.kernel.org/stable/c/bd2a2939423566c654545fa3e96a656662a0af9e","https://git.kernel.org/stable/c/c184bc621e3cef03ac9ba81a50dda2dae6a21d36","https://git.kernel.org/stable/c/cf387cdebfaebae228dfba162f94c567a67610c3","https://git.kernel.org/stable/c/dc583e7e5f8515ca489c0df28e4362a70eade382"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21639 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: rto_min/max: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used. | ["https://git.kernel.org/stable/c/0f78f09466744589e420935e646ae78212a38290","https://git.kernel.org/stable/c/246428bfb9e7db15c5cd08e1d0eca41b65af2b06","https://git.kernel.org/stable/c/4059507e34aa5fe0fa9fd5b2b5f0c8b26ab2d482","https://git.kernel.org/stable/c/9fc17b76fc70763780aa78b38fcf4742384044a5","https://git.kernel.org/stable/c/c87f1f6ade56c711f8736901e330685b453e420e","https://git.kernel.org/stable/c/c8d179f3b1c1d60bf4484f50aa67b4c70f91bff9","https://git.kernel.org/stable/c/dc9d0e3cfd16f66fbf0862857c6b391c8613ca9f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21640 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' is used. | ["https://git.kernel.org/stable/c/03ca51faba2b017bf6c90e139434c4117d0afcdc","https://git.kernel.org/stable/c/3cd0659deb9c03535fd61839e91d4d4d3e51ac71","https://git.kernel.org/stable/c/5599b212d2f4466e1832a94e9932684aaa364587","https://git.kernel.org/stable/c/86ddf8118123cb58a0fb8724cad6979c4069065b","https://git.kernel.org/stable/c/ad673e514b2793b8d5902f6ba6ab7e890dea23d5","https://git.kernel.org/stable/c/ea62dd1383913b5999f3d16ae99d411f41b528d4","https://git.kernel.org/stable/c/f0bb3935470684306e4e04793a20ac4c4b08de0b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21666 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vsock: prevent null-ptr-deref in vsock_*[has_data|has_space] Recent reports have shown how we sometimes call vsock_*_has_data() when a vsock socket has been de-assigned from a transport (see attached links), but we shouldn't. Previous commits should have solved the real problems, but we may have more in the future, so to avoid null-ptr-deref, we can return 0 (no space, no data available) but with a warning. This way the code should continue to run in a nearly consistent state and have a warning that allows us to debug future problems. | ["https://git.kernel.org/stable/c/91751e248256efc111e52e15115840c35d85abaf","https://git.kernel.org/stable/c/9e5fed46ccd2c34c5fa5a9c8825ce4823fdc853e","https://git.kernel.org/stable/c/b52e50dd4fabd12944172bd486a4f4853b7f74dd","https://git.kernel.org/stable/c/bc9c49341f9728c31fe248c5fbba32d2e81a092b","https://git.kernel.org/stable/c/c23d1d4f8efefb72258e9cedce29de10d057f8ca","https://git.kernel.org/stable/c/daeac89cdb03d30028186f5ff7dc26ec8fa843e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21669 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: discard packets if the transport changes If the socket has been de-assigned or assigned to another transport, we must discard any packets received because they are not expected and would cause issues when we access vsk->transport. A possible scenario is described by Hyunwoo Kim in the attached link, where after a first connect() interrupted by a signal, and a second connect() failed, we can find `vsk->transport` at NULL, leading to a NULL pointer dereference. | ["https://git.kernel.org/stable/c/18a7fc371d1dbf8deff16c2dd9292bcc73f43040","https://git.kernel.org/stable/c/2cb7c756f605ec02ffe562fb26828e4bcc5fdfc1","https://git.kernel.org/stable/c/6486915fa661584d70e8e7e4068c6c075c67dd6d","https://git.kernel.org/stable/c/677579b641af109613564460a4e3bdcb16850b61","https://git.kernel.org/stable/c/88244163bc7e7b0ce9dd7bf4c8a563b41525c3ee","https://git.kernel.org/stable/c/d88b249e14bd0ee1e46bbe4f456e22e01b8c68de"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21683 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix bpf_sk_select_reuseport() memory leak As pointed out in the original comment, lookup in sockmap can return a TCP ESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPF set before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cb does not imply a non-refcounted socket. Drop sk's reference in both error paths. unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/0ab52a8ca6e156a64c51b5e7456cac9a0ebfd9bf","https://git.kernel.org/stable/c/b02e70be498b138e9c21701c2f33f4018ca7cd5e","https://git.kernel.org/stable/c/b3af60928ab9129befa65e6df0310d27300942bf","https://git.kernel.org/stable/c/bb36838dac7bb334a3f3d7eb29875593ec9473fc","https://git.kernel.org/stable/c/cccd51dd22574216e64e5d205489e634f86999f3","https://git.kernel.org/stable/c/d0a3b3d1176d39218b8edb2a2d03164942ab9ccd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49974 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. | ["https://git.kernel.org/stable/c/43e46ee5efc03990b223f7aa8b77aa9c3d3acfdf","https://git.kernel.org/stable/c/6a488ad7745b8f64625c6d3a24ce7e448e83f11b","https://git.kernel.org/stable/c/7ea9260874b779637aff6d24c344b8ef4ac862a0","https://git.kernel.org/stable/c/9e52ff544e0bfa09ee339fd7b0937ee3c080c24e","https://git.kernel.org/stable/c/aadc3bbea163b6caaaebfdd2b6c4667fbc726752","https://git.kernel.org/stable/c/ae267989b7b7933dfedcd26468d0a88fc3a9da9e","https://git.kernel.org/stable/c/b4e21431a0db4854b5023cd5af001be557e6c3db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40972 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: do not create EA inode under buffer lock ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers. | ["https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd","https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b","https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752","https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1","https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b","https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46802 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: added NULL check at start of dc_validate_stream [Why] prevent invalid memory access [How] check if dc and stream are NULL | ["https://git.kernel.org/stable/c/154a50bf4221a6a6ccf88d565b8184da7c40a2dd","https://git.kernel.org/stable/c/26c56049cc4f1705b498df013949427692a4b0d5","https://git.kernel.org/stable/c/356fcce9cdbfe338a275e9e1836adfdd7f5c52a9","https://git.kernel.org/stable/c/6bf920193ba1853bad780bba565a789246d9003c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21636 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use '*data' everywhere 'net->sctp.probe_interval' is used. | ["https://git.kernel.org/stable/c/1dc5da6c4178f3e4b95c631418f72de9f86c0449","https://git.kernel.org/stable/c/284a221f8fa503628432c7bb5108277c688c6ffa","https://git.kernel.org/stable/c/44ee8635922b6eb940faddb961a8347c6857d722","https://git.kernel.org/stable/c/6259d2484d0ceff42245d1f09cc8cb6ee72d847a","https://git.kernel.org/stable/c/bcf8c60074e81ed2ac2d35130917175a3949c917"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21637 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: sysctl: udp_port: avoid using current->nsproxy As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons: - Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns. - current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2). The 'net' structure can be obtained from the table->data using container_of(). Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctl_sock' still needs to be retrieved from 'net' structure. | ["https://git.kernel.org/stable/c/0a0966312ac3eedd7f5f2a766ed4702df39a9a65","https://git.kernel.org/stable/c/55627918febdf9d71107a1e68d1528dc591c9a15","https://git.kernel.org/stable/c/5b77d73f3be5102720fb685b9e6900e3500e1096","https://git.kernel.org/stable/c/c10377bbc1972d858eaf0ab366a311b39f8ef1b6","https://git.kernel.org/stable/c/e919197fb8616331f5dc81e4c3cc3d12769cb725"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21665 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: filemap: avoid truncating 64-bit offset to 32 bits On 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a 64-bit value to 32 bits, leading to a possible infinite loop when writing to an xfs filesystem. | ["https://git.kernel.org/stable/c/09528bb1a4123e2a234eac2bc45a0e51e78dab43","https://git.kernel.org/stable/c/280f1fb89afc01e7376f59ae611d54ca69e9f967","https://git.kernel.org/stable/c/64e5fd96330df2ad278d1c4edcca581f26e5f76e","https://git.kernel.org/stable/c/80fc836f3ebe2f2d2d2c80c698b7667974285a04","https://git.kernel.org/stable/c/f505e6c91e7a22d10316665a86d79f84d9f0ba76"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50012 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute. | ["https://git.kernel.org/stable/c/0f41f383b5a61a2bf6429a449ebba7fb08179d81","https://git.kernel.org/stable/c/47cb1d9278f179df8250304ec41009e3e836a926","https://git.kernel.org/stable/c/6c3d8387839252f1a0fc6367f314446e4a2ebd0b","https://git.kernel.org/stable/c/77f88b17387a017416babf1e6488fa17682287e2","https://git.kernel.org/stable/c/c0f02536fffbbec71aced36d52a765f8c4493dc2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix bridge mode operations when there are no VFs Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output. | ["https://git.kernel.org/stable/c/505ae01f75f839b54329164bbfecf24cc1361b31","https://git.kernel.org/stable/c/52c4beb79e095e0631b5cac46ed48a2aefe51985","https://git.kernel.org/stable/c/65feee671e37f3b6eda0b6af28f204b5bcf7fa50","https://git.kernel.org/stable/c/b1d305abef4640af1b4f1b4774d513cd81b10cfc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43913 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme: apple: fix device reference counting Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl. Split the allocation side out to make the error handling boundary easier to navigate. The apple driver had been doing this wrong, leaking the controller device memory on a tagset failure. | ["https://git.kernel.org/stable/c/b9ecbfa45516182cd062fecd286db7907ba84210","https://git.kernel.org/stable/c/d59c4d0eb6adc24c2201f153ccb7fd0a335b0d3d","https://git.kernel.org/stable/c/f7d9a18572fcd7130459b7691bd19ee2a2e951ad"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44963 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not BUG_ON() when freeing tree block after error When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block(). So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection. | ["https://git.kernel.org/stable/c/22d907bcd283d69d5e60497fc0d51969545c583b","https://git.kernel.org/stable/c/98251cd60b4d702a8a81de442ab621e83a3fb24f","https://git.kernel.org/stable/c/bb3868033a4cccff7be57e9145f2117cbdc91c11"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26584 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. | ["https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754","https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368","https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3","https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694","https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72","https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754","https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368","https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3","https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694","https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48946 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. | ["https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e96ac06cf","https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746","https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226","https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7","https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e","https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f","https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852","https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c","https://git.kernel.org/stable/c/cfe4c1b25dd6d2f056afc00b7c98bcb3dd0b1fc3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41088 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: fix infinite loop when xmit fails When the mcp251xfd_start_xmit() function fails, the driver stops processing messages, and the interrupt routine does not return, running indefinitely even after killing the running application. Error messages: [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16 [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3). ... and repeat forever. The issue can be triggered when multiple devices share the same SPI interface. And there is concurrent access to the bus. The problem occurs because tx_ring->head increments even if mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX package while still expecting a response in mcp251xfd_handle_tefif_one(). Resolve the issue by starting a workqueue to write the tx obj synchronously if err = -EBUSY. In case of another error, decrement tx_ring->head, remove skb from the echo stack, and drop the message. [mkl: use more imperative wording in patch description] | ["https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b","https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729","https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510","https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025","https://git.kernel.org/stable/c/3e72558c1711d524e3150103739ddd06650e291b","https://git.kernel.org/stable/c/6c6b4afa59c2fb4d1759235f866d8caed2aa4729","https://git.kernel.org/stable/c/d8fb63e46c884c898a38f061c2330f7729e75510","https://git.kernel.org/stable/c/f926c022ebaabf7963bebf89a97201d66978a025"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41007 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: avoid too many retransmit packets If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'. The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4. | ["https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570","https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982","https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1","https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4","https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283","https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969","https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde","https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466","https://git.kernel.org/stable/c/04317a2471c2f637b4c49cbd0e9c0d04a519f570","https://git.kernel.org/stable/c/5d7e64d70a11d988553a08239c810a658e841982","https://git.kernel.org/stable/c/66cb64a1d2239cd0309f9b5038b05462570a5be1","https://git.kernel.org/stable/c/7bb7670f92bfbd05fc41a8f9a8f358b7ffed65f4","https://git.kernel.org/stable/c/97a9063518f198ec0adb2ecb89789de342bb8283","https://git.kernel.org/stable/c/d2346fca5bed130dc712f276ac63450201d52969","https://git.kernel.org/stable/c/dfcdd7f89e401d2c6616be90c76c2fac3fa98fde","https://git.kernel.org/stable/c/e113cddefa27bbf5a79f72387b8fbd432a61a466"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-40791 | Medium | fixed |
|
extract_user_to_sg in lib/scatterlist.c in the Linux kernel before 6.4.12 fails to unpin pages in a certain situation, as demonstrated by a WARNING for try_grab_page. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f","https://lkml.org/lkml/2023/8/3/323","https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/","https://security.netapp.com/advisory/ntap-20231110-0009/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f443fd5af5dbd531f880d3645d5dd36976cf087f","https://lkml.org/lkml/2023/8/3/323","https://lore.kernel.org/linux-crypto/20571.1690369076%40warthog.procyon.org.uk/","https://security.netapp.com/advisory/ntap-20231110-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50193 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. | ["https://git.kernel.org/stable/c/227358e89703c344008119be7e8ffa3fdb5b92de","https://git.kernel.org/stable/c/43778de19d2ef129636815274644b9c16e78c66b","https://git.kernel.org/stable/c/48a2440d0f20c826b884e04377ccc1e4696c84e9","https://git.kernel.org/stable/c/64adf22c4bc73ede920baca5defefb70f190cdbc","https://git.kernel.org/stable/c/6f44a5fc15b5cece0785bc07453db77d99b0a6de","https://git.kernel.org/stable/c/b6400eb0b347821efc57760221f8fb6d63b9548a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53099 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed. | ["https://git.kernel.org/stable/c/24fec234d2ba9ca3c14e545ebe3fd6dcb47f074d","https://git.kernel.org/stable/c/4e8074bb33d18f56af30a0252cb3606d27eb1c13","https://git.kernel.org/stable/c/79f87a6ec39fb5968049a6775a528bf58b25c20a","https://git.kernel.org/stable/c/8421d4c8762bd022cb491f2f0f7019ef51b4f0a7","https://git.kernel.org/stable/c/b3eb1b6a9f745d6941b345f0fae014dc8bb06d36","https://git.kernel.org/stable/c/d5092b0a1aaf35d77ebd8d33384d7930bec5cb5d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46724 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_number Check the fb_channel_number range to avoid the array out-of-bounds read error | ["https://git.kernel.org/stable/c/32915dc909ff502823babfe07d5416c5b6e8a8b1","https://git.kernel.org/stable/c/45f7b02afc464c208e8f56bcbc672ef5c364c815","https://git.kernel.org/stable/c/725b728cc0c8c5fafdfb51cb0937870d33a40fa4","https://git.kernel.org/stable/c/d768394fa99467bcf2703bde74ddc96eeb0b71fa","https://git.kernel.org/stable/c/db7a86676fd624768a5d907faf34ad7bb4ff25f4","https://git.kernel.org/stable/c/f9267972490f9fcffe146e79828e97acc0da588c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46731 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix the Out-of-bounds read warning using index i - 1U may beyond element index for mc_data[] when i = 0. | ["https://git.kernel.org/stable/c/12c6967428a099bbba9dfd247bb4322a984fcc0b","https://git.kernel.org/stable/c/20c6373a6be93039f9d66029bb1e21038a060be1","https://git.kernel.org/stable/c/3317966efcdc5101e93db21514b68917e7eb34ea","https://git.kernel.org/stable/c/38e32a0d837443c91c4b615a067b976cfb925376","https://git.kernel.org/stable/c/d83fb9f9f63e9a120bf405b078f829f0b2e58934","https://git.kernel.org/stable/c/f1e261ced9bcad772a45a2fcdf413c3490e87299"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50035 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 | ["https://git.kernel.org/stable/c/30d91a478d58cbae3dbaa8224d17d0d839f0d71b","https://git.kernel.org/stable/c/40dddd4b8bd08a69471efd96107a4e1c73fabefc","https://git.kernel.org/stable/c/4151ec65abd755133ebec687218fadd2d2631167","https://git.kernel.org/stable/c/8dfe93901b410ae41264087427f3b9f389388f83","https://git.kernel.org/stable/c/8fe992ff3df493d1949922ca234419f3ede08dff","https://git.kernel.org/stable/c/c007a14797240607038bd3464501109f408940e2","https://git.kernel.org/stable/c/ce249a4c68d0ce27a8c5d853338d502e2711a314","https://git.kernel.org/stable/c/fadf8fdb3110d3138e05c3765f645535434f8d76"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-26365 | High | fixed |
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). | ["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33741 | High | fixed |
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). | ["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50059 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove. | ["https://git.kernel.org/stable/c/177925d9c8715a897bb79eca62628862213ba956","https://git.kernel.org/stable/c/3ae45be8492460a35b5aebf6acac1f1d32708946","https://git.kernel.org/stable/c/5126d8f5567f49b52e21fca320eaa97977055099","https://git.kernel.org/stable/c/92728fceefdaa2a0a3aae675f86193b006eeaa43","https://git.kernel.org/stable/c/b650189687822b705711f0567a65a164a314d8df","https://git.kernel.org/stable/c/e51aded92d42784313ba16c12f4f88cc4f973bbb","https://git.kernel.org/stable/c/fa840ba4bd9f3bad7f104e5b32028ee73af8b3dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1998 | Medium | fixed |
|
The Linux kernel allows userspace processes to enable mitigations by calling prctl with PR_SET_SPECULATION_CTRL which disables the speculation feature as well as by using seccomp. We had noticed that on VMs of at least one major cloud provider, the kernel still left the victim process exposed to attacks in some cases even after enabling the spectre-BTI mitigation with prctl. The same behavior can be observed on a bare-metal machine when forcing the mitigation to IBRS on boot command line. This happened because when plain IBRS was enabled (not enhanced IBRS), the kernel had some logic that determined that STIBP was not needed. The IBRS bit implicitly protects against cross-thread branch target injection. However, with legacy IBRS, the IBRS bit was cleared on returning to userspace, due to performance reasons, which disabled the implicit STIBP and left userspace threads vulnerable to cross-thread branch target injection against which STIBP protects. | ["https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx","https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://github.com/google/security-research/security/advisories/GHSA-mj4w-6495-6crx","https://github.com/torvalds/linux/commit/6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://kernel.dance/#6921ed9049bc7457f66c1596c5b78aec0dae4a9d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57874 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently tagged_addr_ctrl_set() will consume an arbitrary value, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism. As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and rejects other values, a partial SETREGSET attempt will randomly succeed or fail depending on the value of the uninitialized value, and the exposure is significantly limited. Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG, NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing value of the tagged address ctrl will be retained. The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the user_aarch64_view used by a native AArch64 task to manipulate another native AArch64 task. As get_tagged_addr_ctrl() only returns an error value when called for a compat task, tagged_addr_ctrl_get() and tagged_addr_ctrl_set() should never observe an error value from get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that such an error would be unexpected, and error handlnig is not missing in either case. | ["https://git.kernel.org/stable/c/1152dd13845efde5554f80c7e1233bae1d26bd3e","https://git.kernel.org/stable/c/1370cf3eb5495d70e00547598583a4cd45b40b99","https://git.kernel.org/stable/c/1c176f5155ee6161fee6f416b64aa50394d3f220","https://git.kernel.org/stable/c/96035c0093db258975b8887676afe59a64c34a72","https://git.kernel.org/stable/c/abd614bbfcee73247495bd9472da8f85ac83546e","https://git.kernel.org/stable/c/ca62d90085f4af36de745883faab9f8a7cbb45d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48698 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix memory leak when using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. Fix this up by properly calling dput(). | ["https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05","https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54","https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2","https://git.kernel.org/stable/c/3a6279d243cb035eaaff1450980b40cf19748f05","https://git.kernel.org/stable/c/58acd2ebae034db3bacf38708f508fbd12ae2e54","https://git.kernel.org/stable/c/cbfac7fa491651c57926c99edeb7495c6c1aeac2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56672 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. | ["https://git.kernel.org/stable/c/29d1e06560f0f6179062ac638b4064deb637d1ad","https://git.kernel.org/stable/c/5baa28569c924d9a90d036c2aaab79f791fedaf8","https://git.kernel.org/stable/c/64afc6fe24c9896c0153e5a199bcea241ecb0d5c","https://git.kernel.org/stable/c/83f5a87ee8caa76a917f59912a74d6811f773c67","https://git.kernel.org/stable/c/86e6ca55b83c575ab0f2e105cf08f98e58d3d7af","https://git.kernel.org/stable/c/8a07350fe070017a887433f4d6909433955be5f1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35888 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: erspan: make sure erspan_base_hdr is present in skb->head syzbot reported a problem in ip6erspan_rcv() [1] Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make sure erspan_base_hdr is present in skb linear part (skb->head) before getting @ver field from it. Add the missing pskb_may_pull() calls. v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed. [1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0 | ["https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac","https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446","https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0","https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d","https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d","https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85","https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5","https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7","https://git.kernel.org/stable/c/06a939f72a24a7d8251f84cf4c042df86c6666ac","https://git.kernel.org/stable/c/0ac328a5a4138a6c03dfc3f46017bd5c19167446","https://git.kernel.org/stable/c/17af420545a750f763025149fa7b833a4fc8b8f0","https://git.kernel.org/stable/c/1db7fcb2b290c47c202b79528824f119fa28937d","https://git.kernel.org/stable/c/4e3fdeecec5707678b0d1f18c259dadb97262e9d","https://git.kernel.org/stable/c/b14b9f9503ec823ca75be766dcaeff4f0bfeca85","https://git.kernel.org/stable/c/e54a0c79cdc2548729dd7e2e468b08c5af4d0df5","https://git.kernel.org/stable/c/ee0088101beee10fa809716d6245d915b09c37c7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26756 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread. | ["https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417","https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe","https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417","https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46750 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: Add missing bridge lock to pci_bus_lock() One of the true positives that the cfg_access_lock lockdep effort identified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: <TASK> ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120 Where pci_reset_bus() users are triggering unlocked secondary bus resets. Ironically pci_bus_reset(), several calls down from pci_reset_bus(), uses pci_bus_lock() before issuing the reset which locks everything *but* the bridge itself. For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge); to pci_reset_function() for the "bus" and "cxl_bus" reset cases, add pci_dev_lock() for @bus->self to pci_bus_lock(). [bhelgaas: squash in recursive locking deadlock fix from Keith Busch: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com] | ["https://git.kernel.org/stable/c/04e85a3285b0e5c5af6fd2c0fd6e95ffecc01945","https://git.kernel.org/stable/c/0790b89c7e911003b8c50ae50e3ac7645de1fae9","https://git.kernel.org/stable/c/7253b4fed46471cc247c6cacefac890a8472c083","https://git.kernel.org/stable/c/78c6e39fef5c428960aff742149bba302dd46f5a","https://git.kernel.org/stable/c/81c68e218ab883dfa368460a59b674084c0240da","https://git.kernel.org/stable/c/a4e772898f8bf2e7e1cf661a12c60a5612c4afab","https://git.kernel.org/stable/c/df77a678c33871a6e4ac5b54a71662f1d702335b","https://git.kernel.org/stable/c/e2355d513b89a2cb511b4ded0deb426cdb01acd0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53093 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work. | ["https://git.kernel.org/stable/c/1f021341eef41e77a633186e9be5223de2ce5d48","https://git.kernel.org/stable/c/4a57f42e5ed42cb8f1beb262c4f6d3e698939e4e","https://git.kernel.org/stable/c/60de2e03f984cfbcdc12fa552f95087c35a05a98","https://git.kernel.org/stable/c/a91b7eddf45afeeb9c5ece11dddff5de0921b00f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48850 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net-sysfs: add check for netdevice being present to speed_show When bringing down the netdevice or system shutdown, a panic can be triggered while accessing the sysfs path because the device is already removed. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER) To prevent this scenario, we also make sure that the netdevice is present. | ["https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad","https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204","https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624","https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f","https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2","https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6","https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2","https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c","https://git.kernel.org/stable/c/081369ad088a76429984483b8a5f7e967a125aad","https://git.kernel.org/stable/c/3a79f380b3e10edf6caa9aac90163a5d7a282204","https://git.kernel.org/stable/c/4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624","https://git.kernel.org/stable/c/75fc8363227a999e8f3d17e2eb28dce5600dcd3f","https://git.kernel.org/stable/c/8879b5313e9fa5e0c6d6812a0d25d83aed0110e2","https://git.kernel.org/stable/c/8d5e69d8fbf3a35ab4fbe56b8f092802b43f3ef6","https://git.kernel.org/stable/c/a7b9ab04c5932dee7ec95e0abc58b0df350c0dd2","https://git.kernel.org/stable/c/d15c9f6e3335002fea1c33bc8f71a705fa96976c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix division by zero in setup_dsc_config When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113. | ["https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba","https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911","https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639","https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f","https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445","https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563","https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba","https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911","https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639","https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f","https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445","https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42069 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix possible double free in error handling path When auxiliary_device_add() returns error and then calls auxiliary_device_uninit(), callback function adev_release calls kfree(madev). We shouldn't call kfree(madev) again in the error handling path. Set 'madev' to NULL. | ["https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc","https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a","https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4","https://git.kernel.org/stable/c/1864b8224195d0e43ddb92a8151f54f6562090cc","https://git.kernel.org/stable/c/3243e64eb4d897c3eeb48b2a7221ab5a95e1282a","https://git.kernel.org/stable/c/ed45c0a0b662079d4c0e518014cc148c753979b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. | ["https://git.kernel.org/stable/c/7f8e93b862aba08d540f1e9e03e0ceb4d0cfd5fb","https://git.kernel.org/stable/c/9be768f08b16f020da376538b08463ac3a2ce8cd","https://git.kernel.org/stable/c/9f35cec5e4b9759b38c663d18eae4eaf30f36527","https://git.kernel.org/stable/c/b995c0a6de6c74656a0c39cd57a0626351b13e3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-39190 | Medium | fixed |
|
An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel before 5.19.6. A denial of service can occur upon binding to an already bound chain. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6","https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/","https://twitter.com/pr0Ln","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19.6","https://github.com/torvalds/linux/commit/e02f0d3970404bfea385b6edb86f2d936db0ea2b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/20220824220330.64283-12-pablo%40netfilter.org/","https://twitter.com/pr0Ln"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49937 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list] | ["https://git.kernel.org/stable/c/04053e55dd50741cf6c59b9bbaa4238218c05c70","https://git.kernel.org/stable/c/20361712880396e44ce80aaeec2d93d182035651","https://git.kernel.org/stable/c/95f32191e50b75e0f75fae1bb925cdf51d8df0a3","https://git.kernel.org/stable/c/c628026563f4ea9e0413dd4b69429e4a1db240b1","https://git.kernel.org/stable/c/f4dbfda159e43d49b43003cc3c2914751939035f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41012 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: filelock: Remove locks reliably when fcntl/close race is detected When fcntl_setlk() races with close(), it removes the created lock with do_lock_file_wait(). However, LSMs can allow the first do_lock_file_wait() that created the lock while denying the second do_lock_file_wait() that tries to remove the lock. Separately, posix_lock_file() could also fail to remove a lock due to GFP_KERNEL allocation failure (when splitting a range in the middle). After the bug has been triggered, use-after-free reads will occur in lock_get_status() when userspace reads /proc/locks. This can likely be used to read arbitrary kernel memory, but can't corrupt kernel memory. Fix it by calling locks_remove_posix() instead, which is designed to reliably get rid of POSIX locks associated with the given file and files_struct and is also used by filp_flush(). | ["https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9","https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22","https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240","https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763","https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224","https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250","https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235","https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3","https://git.kernel.org/stable/c/3cad1bc010416c6dd780643476bc59ed742436b9","https://git.kernel.org/stable/c/52c87ab18c76c14d7209646ccb3283b3f5d87b22","https://git.kernel.org/stable/c/5661b9c7ec189406c2dde00837aaa4672efb6240","https://git.kernel.org/stable/c/5f5d0799eb0a01d550c21b7894e26b2d9db55763","https://git.kernel.org/stable/c/b6d223942c34057fdfd8f149e763fa823731b224","https://git.kernel.org/stable/c/d30ff33040834c3b9eee29740acd92f9c7ba2250","https://git.kernel.org/stable/c/dc2ce1dfceaa0767211a9d963ddb029ab21c4235","https://git.kernel.org/stable/c/ef8fc41cd6f95f9a4a3470f085aecf350569a0b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49924 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime. | ["https://git.kernel.org/stable/c/3c0d416eb4bef705f699213cee94bf54b6acdacd","https://git.kernel.org/stable/c/4a6921095eb04a900e0000da83d9475eb958e61e","https://git.kernel.org/stable/c/4cda484e584be34d55ee17436ebf7ad11922b97a","https://git.kernel.org/stable/c/6d0a07f68b66269e167def6c0b90a219cd3e7473","https://git.kernel.org/stable/c/a3a855764dbacbdb1cc51e15dc588f2d21c93e0e","https://git.kernel.org/stable/c/aaadc0cb05c999ccd8898a03298b7e5c31509b08","https://git.kernel.org/stable/c/e657fa2df4429f3805a9b3e47fb1a4a1b02a72bd","https://git.kernel.org/stable/c/e6897e299f57b103e999e62010b88e363b3eebae","https://git.kernel.org/stable/c/fdda354f60a576d52dcf90351254714681df4370"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50007 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size. | ["https://git.kernel.org/stable/c/219587bca2678e31700ef09ecec178ba1f735674","https://git.kernel.org/stable/c/36ee4021bcc37b834996e79740d095d6f8dd948f","https://git.kernel.org/stable/c/7a55740996701f7b2bc46dc988b60ef2e416a747","https://git.kernel.org/stable/c/7b986c7430a6bb68d523dac7bfc74cbd5b44ef96","https://git.kernel.org/stable/c/876d04bf5a8ac1d6af5afd258cd37ab83ab2cf3d","https://git.kernel.org/stable/c/a6bdb691cf7b66dcd929de1a253c5c42edd2e522","https://git.kernel.org/stable/c/ad7248a5e92587b9266c62db8bcc4e58de53e372","https://git.kernel.org/stable/c/ce2953e44829ec54bcbb57e9d890fc8af0900c80","https://git.kernel.org/stable/c/e658227d9d4f4e122d81690fdbc0d438b10288f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53142 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + "\0" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar="A" # change to "\0" to properly zero terminate / pad magic="070701" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname="initramfs_test_fname_overrun" namelen=$(( ${#fname} + 1 )) # plus one to account for terminator printf "%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s" \ $magic $ino $mode $uid $gid $nlink $mtime $filesize \ $devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf "%.s${nilchar}" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset. | ["https://git.kernel.org/stable/c/1a423bbbeaf9e3e20c4686501efd9b661fe834db","https://git.kernel.org/stable/c/49d01e736c3045319e030d1e75fb983011abaca7","https://git.kernel.org/stable/c/6983b8ac787b3add5571cda563574932a59a99bb","https://git.kernel.org/stable/c/bb7ac96670ab1d8d681015f9d66e45dad579af4d","https://git.kernel.org/stable/c/c509b1acbd867d9e09580fe059a924cb5825afb1","https://git.kernel.org/stable/c/d3df9f26cff97beaa5643e551031795d5d5cddbe","https://git.kernel.org/stable/c/e017671f534dd3f568db9e47b0583e853d2da9b5","https://git.kernel.org/stable/c/f892ddcf9f645380c358e73653cb0900f6bc9eb8","https://git.kernel.org/stable/c/fb83b093f75806333b6f4ae29b158d2e0e3ec971"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40902 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: xattr: fix buffer overflow for invalid xattr When an xattr size is not what is expected, it is printed out to the kernel log in hex format as a form of debugging. But when that xattr size is bigger than the expected size, printing it out can cause an access off the end of the buffer. Fix this all up by properly restricting the size of the debug hex dump in the kernel log. | ["https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a","https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123","https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69","https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7","https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f","https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f","https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f","https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0","https://git.kernel.org/stable/c/1e84c9b1838152a87cf453270a5fa75c5037e83a","https://git.kernel.org/stable/c/33aecc5799c93d3ee02f853cb94e201f9731f123","https://git.kernel.org/stable/c/4598233d9748fe4db4e13b9f473588aa25e87d69","https://git.kernel.org/stable/c/480e5bc21f2c42d90c2c16045d64d824dcdd5ec7","https://git.kernel.org/stable/c/7c55b78818cfb732680c4a72ab270cc2d2ee3d0f","https://git.kernel.org/stable/c/b537cb2f4c4a1357479716a9c339c0bda03d873f","https://git.kernel.org/stable/c/f0dedb5c511ed82cbaff4997a8decf2351ba549f","https://git.kernel.org/stable/c/fc745f6e83cb650f9a5f2c864158e3a5ea76dad0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50112 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/lam: Disable ADDRESS_MASKING in most cases Linear Address Masking (LAM) has a weakness related to transient execution as described in the SLAM paper[1]. Unless Linear Address Space Separation (LASS) is enabled this weakness may be exploitable. Until kernel adds support for LASS[2], only allow LAM for COMPILE_TEST, or when speculation mitigations have been disabled at compile time, otherwise keep LAM disabled. There are no processors in market that support LAM yet, so currently nobody is affected by this issue. [1] SLAM: https://download.vusec.net/papers/slam_sp24.pdf [2] LASS: https://lore.kernel.org/lkml/20230609183632.48706-1-alexander.shishkin@linux.intel.com/ [ dhansen: update SPECULATION_MITIGATIONS -> CPU_MITIGATIONS ] | ["https://git.kernel.org/stable/c/3267cb6d3a174ff83d6287dcd5b0047bbd912452","https://git.kernel.org/stable/c/60a5ba560f296ad8da153f6ad3f70030bfa3958f","https://git.kernel.org/stable/c/690599066488d16db96ac0d6340f9372fc56f337"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21687 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/platform: check the bounds of read/write syscalls count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device. | ["https://git.kernel.org/stable/c/1485932496a1b025235af8aa1e21988d6b7ccd54","https://git.kernel.org/stable/c/665cfd1083866f87301bbd232cb8ba48dcf4acce","https://git.kernel.org/stable/c/6bcb8a5b70b80143db9bf12dfa7d53636f824d53","https://git.kernel.org/stable/c/92340e6c5122d823ad064984ef7513eba9204048","https://git.kernel.org/stable/c/9377cdc118cf327248f1a9dde7b87de067681dc9","https://git.kernel.org/stable/c/a20fcaa230f7472456d12cf761ed13938e320ac3","https://git.kernel.org/stable/c/c981c32c38af80737a2fedc16e270546d139ccdd","https://git.kernel.org/stable/c/ce9ff21ea89d191e477a02ad7eabf4f996b80a69","https://git.kernel.org/stable/c/d19a8650fd3d7aed8d1af1d9a77f979a8430eba1","https://git.kernel.org/stable/c/ed81d82bb6e9df3a137f2c343ed689e6c68268ef","https://git.kernel.org/stable/c/f21636f24b6786c8b13f1af4319fa75ffcf17f38","https://git.kernel.org/stable/c/f65ce06387f8c1fb54bd59e18a8428248ec68eaf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49023 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix buffer overflow in elem comparison For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length. | ["https://git.kernel.org/stable/c/391cb872553627bdcf236c03ee7d5adb275e37e1","https://git.kernel.org/stable/c/88a6fe3707888bd1893e9741157a7035c4159ab6","https://git.kernel.org/stable/c/9e6b79a3cd17620d467311b30d56f2648f6880aa","https://git.kernel.org/stable/c/9f16b5c82a025cd4c864737409234ddc44fb166a","https://git.kernel.org/stable/c/f5c2ec288a865dbe3706b09bed12302e9f6d696b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58002 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled. | ["https://git.kernel.org/stable/c/117f7a2975baa4b7d702d3f4830d5a4ebd0c6d50","https://git.kernel.org/stable/c/221cd51efe4565501a3dbf04cc011b537dcce7fb","https://git.kernel.org/stable/c/2a29413ace64627e178fd422dd8a5d95219a2c0b","https://git.kernel.org/stable/c/438bda062b2c40ddd7df23b932e29ffe0a448cac","https://git.kernel.org/stable/c/4dbaa738c583a0e947803c69e8996e88cf98d971","https://git.kernel.org/stable/c/653993f46861f2971e95e9a0e36a34b49dec542c","https://git.kernel.org/stable/c/9edc7d25f7e49c33a1ce7a5ffadea2222065516c","https://git.kernel.org/stable/c/ac18d781466252cd35a3e311e0a4b264260fd927"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21785 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level). | ["https://git.kernel.org/stable/c/4371ac7b494e933fffee2bd6265d18d73c4f05aa","https://git.kernel.org/stable/c/4ff25f0b18d1d0174c105e4620428bcdc1213860","https://git.kernel.org/stable/c/67b99a2b5811df4294c2ad50f9bff3b6a08bd618","https://git.kernel.org/stable/c/715eb1af64779e1b1aa0a7b2ffb81414d9f708e5","https://git.kernel.org/stable/c/875d742cf5327c93cba1f11e12b08d3cce7a88d2","https://git.kernel.org/stable/c/88a3e6afaf002250220793df99404977d343db14","https://git.kernel.org/stable/c/ab90894f33c15b14c1cee6959ab6c8dcb09127f8","https://git.kernel.org/stable/c/e4fde33107351ec33f1a64188612fbc6ca659284"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21858 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: geneve: Fix use-after-free in geneve_find_dev(). syzkaller reported a use-after-free in geneve_find_dev() [0] without repro. geneve_configure() links struct geneve_dev.next to net_generic(net, geneve_net_id)->geneve_list. The net here could differ from dev_net(dev) if IFLA_NET_NS_PID, IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set. When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finally calls unregister_netdevice_queue() for each dev in the netns, and later the dev is freed. However, its geneve_dev.next is still linked to the backend UDP socket netns. Then, use-after-free will occur when another geneve dev is created in the netns. Let's call geneve_dellink() instead in geneve_destroy_tunnels(). [0]: BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline] BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441 CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3d Hardware name: linux,dummy-virt (DT) Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600 Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n ---truncated--- | ["https://git.kernel.org/stable/c/3ce92ca990cfac88a87c61df3cc0b5880e688ecf","https://git.kernel.org/stable/c/5a0538ac6826807d6919f6aecbb8996c2865af2c","https://git.kernel.org/stable/c/788dbca056a8783ec063da3c9d49a3a71c76c283","https://git.kernel.org/stable/c/904e746b2e7fa952ab8801b303ce826a63153d78","https://git.kernel.org/stable/c/9593172d93b9f91c362baec4643003dc29802929","https://git.kernel.org/stable/c/d5e86e27de0936f3cb0a299ce519d993e9cf3886","https://git.kernel.org/stable/c/da9b0ae47f084014b1e4b3f31f70a0defd047ff3","https://git.kernel.org/stable/c/f74f6560146714241c6e167b03165ee77a86e316"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48990 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free during gpu recovery [Why] [ 754.862560] refcount_t: underflow; use-after-free. [ 754.862898] Call Trace: [ 754.862903] <TASK> [ 754.862913] amdgpu_job_free_cb+0xc2/0xe1 [amdgpu] [ 754.863543] drm_sched_main.cold+0x34/0x39 [amd_sched] [How] The fw_fence may be not init, check whether dma_fence_init is performed before job free | ["https://git.kernel.org/stable/c/3cb93f390453cde4d6afda1587aaa00e75e09617","https://git.kernel.org/stable/c/d2a89cd942edd50c1e652004fd64019be78b0a96"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2007 | High | fixed |
|
The specific flaw exists within the DPT I2O Controller driver. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute arbitrary code in the context of the kernel. | ["https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240119-0011/","https://www.debian.org/security/2023/dsa-5480","https://github.com/torvalds/linux/commit/b04e75a4a8a81887386a0d2dbf605a48e779d2a0","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240119-0011/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47521 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_CHANNEL_LIST in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when parsing the operating channel attribute from Wi-Fi management frames. | ["https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/f9b62f9843c7b0afdaecabbcebf1dbba18599408","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-4-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26608 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix global oob in ksmbd_nl_policy Similar to a reported issue (check the commit b33fb5b801c6 ("net: qualcomm: rmnet: fix global oob in rmnet_policy"), my local fuzzer finds another global out-of-bounds read for policy ksmbd_nl_policy. See bug trace below: ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810 CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 __nlmsg_parse include/net/netlink.h:748 [inline] genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565 genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734 genl_family_rcv_msg net/netlink/genetlink.c:833 [inline] genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdd66a8f359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003 RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 </TASK> The buggy address belongs to the variable: ksmbd_nl_policy+0x100/0xa80 The buggy address belongs to the physical page: page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9 ^ ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05 ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9 ================================================================== To fix it, add a placeholder named __KSMBD_EVENT_MAX and let KSMBD_EVENT_MAX to be its original value - 1 according to what other netlink families do. Also change two sites that refer the KSMBD_EVENT_MAX to correct value. | ["https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a","https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95","https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d","https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5","https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa","https://git.kernel.org/stable/c/2c939c74ef0b74e99b92e32edc2a59f9b9ca3d5a","https://git.kernel.org/stable/c/6993328a4cd62a24df254b587c0796a4a1eecc95","https://git.kernel.org/stable/c/9863a53100f47652755545c2bd43e14a1855104d","https://git.kernel.org/stable/c/aaa1f1a2ee80888c12ae2783f3a0be10e14067c5","https://git.kernel.org/stable/c/ebeae8adf89d9a82359f6659b1663d09beec2faa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52870 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data Add the check for the return value of mtk_alloc_clk_data() in order to avoid NULL pointer dereference. | ["https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480","https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a","https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946","https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc","https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830","https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f","https://git.kernel.org/stable/c/10cc81124407d862f0f747db4baa9c006510b480","https://git.kernel.org/stable/c/2617aa8ceaf30e41d3eb7f5fef3445542bef193a","https://git.kernel.org/stable/c/533ca5153ad6c7b7d47ae0114b14d0333964b946","https://git.kernel.org/stable/c/b5ff3e89b4e7f46ad2aa0de7e08d18e6f87d71bc","https://git.kernel.org/stable/c/b82681042724924ae3ba0f2f2eeec217fa31e830","https://git.kernel.org/stable/c/dd1f30d68fa98eb672c0a259297b761656a9025f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3565 | High | fixed |
|
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function del_timer of the file drivers/isdn/mISDN/l1oip_core.c of the component Bluetooth. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211088. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211088","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211088"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1671 | High | fixed |
|
A NULL pointer dereference flaw was found in rxrpc_preparse_s in net/rxrpc/server_key.c in the Linux kernel. This flaw allows a local attacker to crash the system or leak internal kernel information. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87","https://security.netapp.com/advisory/ntap-20220901-0004/","https://security.netapp.com/advisory/ntap-20220901-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff8376ade4f668130385839cef586a0990f8ef87","https://security.netapp.com/advisory/ntap-20220901-0004/","https://security.netapp.com/advisory/ntap-20220901-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48966 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mvneta: Prevent out of bounds read in mvneta_config_rss() The pp->indir[0] value comes from the user. It is passed to: if (cpu_online(pp->rxq_def)) inside the mvneta_percpu_elect() function. It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap. | ["https://git.kernel.org/stable/c/146ebee8fcdb349d7ec0e49915e6cdafb92544ae","https://git.kernel.org/stable/c/3ceffb8f410b93553fb16fe7e84aa0d35b3ba79b","https://git.kernel.org/stable/c/47a1a2f6cd5ec3a4f8a2d9bfa1e0605347cdb92c","https://git.kernel.org/stable/c/5a142486a0db6b0b85031f22d69acd0cdcf8f72b","https://git.kernel.org/stable/c/6ca0a506dddc3e1d636935eef339576b263bf3d8","https://git.kernel.org/stable/c/a6b30598fec84f8809f5417cde73071ca43e8471","https://git.kernel.org/stable/c/e8b4fc13900b8e8be48debffd0dfd391772501f7","https://git.kernel.org/stable/c/eec1fc21edc2bb99c9e66cf66f0b5d4d643fbb50"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49031 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4403: Fix oob read in afe4403_read_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279 Call Trace: afe4403_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4403_channel_leds+0x18/0xffffffffffffe9e0 This issue can be reproduced by singe command: $ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw The array size of afe4403_channel_leds is less than channels, so access with chan->address cause OOB read in afe4403_read_raw. Fix it by moving access before use it. | ["https://git.kernel.org/stable/c/06c6ce21cec77dfa860d57e7a006000a57812efb","https://git.kernel.org/stable/c/2d6a437064ffbe685c67ddb16dfc0946074c6c3f","https://git.kernel.org/stable/c/58143c1ed5882c138a3cd2251a336fc8755f23d9","https://git.kernel.org/stable/c/726fa3e4ab97dcff1c745bdc4fb137366cb8d3df","https://git.kernel.org/stable/c/98afcb5f3be645d330c74c5194ba0d80e26f95e0","https://git.kernel.org/stable/c/b1756af172fb80a3edc143772d49e166ec691b6c","https://git.kernel.org/stable/c/c9268df36818ee4eaaaeadc80009b442a5ca69c9","https://git.kernel.org/stable/c/e7e76a77aabef8989cbc0a8417af1aa040620867"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49032 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw KASAN report out-of-bounds read as follows: BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278 Call Trace: afe4404_read_raw iio_read_channel_info dev_attr_show The buggy address belongs to the variable: afe4404_channel_leds+0x18/0xffffffffffffe9c0 This issue can be reproduce by singe command: $ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan->address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them. | ["https://git.kernel.org/stable/c/113c08030a89aaf406f8a1d4549d758a67c2afba","https://git.kernel.org/stable/c/3f566b626029ca8598d48e5074e56bb37399ca1b","https://git.kernel.org/stable/c/5eb114f55b37dbc0487aa9c1913b81bb7837f1c4","https://git.kernel.org/stable/c/68de7da092f38395dde523f2e5db26eba6c23e28","https://git.kernel.org/stable/c/d45d9f45e7b1365fd0d9bf14680d6d5082a590d1","https://git.kernel.org/stable/c/f5575041ec15310bdc50c42b8b22118cc900226e","https://git.kernel.org/stable/c/f7419fc42afc035f6b29ce713e17dcd2000c833f","https://git.kernel.org/stable/c/fc92d9e3de0b2d30a3ccc08048a5fad533e4672b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52640 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea. | ["https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c","https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23","https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb","https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15","https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd","https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c","https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23","https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb","https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15","https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52503 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return 'sess' that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of 'sess' from session list in destroy_session() as a critical section, so that it is executed atomically. | ["https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116","https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce","https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c","https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27","https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f","https://git.kernel.org/stable/c/1680c82929bc14d706065f123dab77f2f1293116","https://git.kernel.org/stable/c/1c95574350cd63bc3c5c2fa06658010768f2a0ce","https://git.kernel.org/stable/c/60c3e7a00db954947c265b55099c21b216f2a05c","https://git.kernel.org/stable/c/da7ce52a2f6c468946195b116615297d3d113a27","https://git.kernel.org/stable/c/f4384b3e54ea813868bb81a861bf5b2406e15d8f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48687 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET. | ["https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa","https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c","https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093","https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3","https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35","https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864","https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab","https://git.kernel.org/stable/c/076f2479fc5a15c4a970ca3b5e57d42ba09a31fa","https://git.kernel.org/stable/c/3df71e11a4773d775c3633c44319f7acdb89011c","https://git.kernel.org/stable/c/55195563ec29f80f984237b743de0e2b6ba4d093","https://git.kernel.org/stable/c/56ad3f475482bca55b0ae544031333018eb145b3","https://git.kernel.org/stable/c/84a53580c5d2138c7361c7c3eea5b31827e63b35","https://git.kernel.org/stable/c/dc9dbd65c803af1607484fed5da50d41dc8dd864","https://git.kernel.org/stable/c/f684c16971ed5e77dfa25a9ad25b5297e1f58eab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46841 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc() We handle errors here properly, ENOMEM isn't fatal, return the error. | ["https://git.kernel.org/stable/c/135b4819f6fba87fd5a2693023133e78ac73f1d3","https://git.kernel.org/stable/c/44a2c518ab221c0cadcb8c45ca86f83a52dd4da6","https://git.kernel.org/stable/c/6a0648f96c3ca647c71c6c1ddbc7c353bab79f64","https://git.kernel.org/stable/c/704c359b4093a2af650a20eaa030c435d7c30f91","https://git.kernel.org/stable/c/a580fb2c3479d993556e1c31b237c9e5be4944a3","https://git.kernel.org/stable/c/c1406d8329f500e4594cd9730cd313aebc3a4333"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50272 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the "localio" optimisation for loopback NFS mounts. | ["https://git.kernel.org/stable/c/26530b757c81f1389fb33ae0357500150933161b","https://git.kernel.org/stable/c/6450e73f4c86d481ac2e22e1bc848d346e140826","https://git.kernel.org/stable/c/6cc52df69e8464811f9f6fc12f7aaa78451eb0b8","https://git.kernel.org/stable/c/a2746ab3bbc9c6408da5cd072653ec8c24749235","https://git.kernel.org/stable/c/ace149e0830c380ddfce7e466fe860ca502fe4ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43849 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: protect locator_addr with the main mutex If the service locator server is restarted fast enough, the PDR can rewrite locator_addr fields concurrently. Protect them by placing modification of those fields under the main pdr->lock. | ["https://git.kernel.org/stable/c/107924c14e3ddd85119ca43c26a4ee1056fa9b84","https://git.kernel.org/stable/c/3e815626d73e05152a8142f6e44aecc4133e6e08","https://git.kernel.org/stable/c/475a77fb3f0e1d527f56c60b79f5879661df5b80","https://git.kernel.org/stable/c/8543269567e2fb3d976a8255c5e348aed14f98bc","https://git.kernel.org/stable/c/d0870c4847e77a49c2f91bb2a8e0fa3c1f8dea5c","https://git.kernel.org/stable/c/eab05737ee22216250fe20d27f5a596da5ea6eb7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binfmt_flat: Fix integer overflow bug on 32 bit systems Most of these sizes and counts are capped at 256MB so the math doesn't result in an integer overflow. The "relocs" count needs to be checked as well. Otherwise on 32bit systems the calculation of "full_data" could be wrong. full_data = data_len + relocs * sizeof(unsigned long); | ["https://git.kernel.org/stable/c/0b6be54d7386b7addbf9e5947366f94aad046938","https://git.kernel.org/stable/c/55cf2f4b945f6a6416cc2524ba740b83cc9af25a","https://git.kernel.org/stable/c/6fb98e0576ea155267e206286413dcb3a3d55c12","https://git.kernel.org/stable/c/8e8cd712bb06a507b26efd2a56155076aa454345","https://git.kernel.org/stable/c/95506c7f33452450346fbe2975c1359100f854ca","https://git.kernel.org/stable/c/a009378af674b808efcca1e2e67916e79ce866b3","https://git.kernel.org/stable/c/bc8ca18b8ef4648532c001bd6c8151143b569275","https://git.kernel.org/stable/c/d17ca8f2dfcf423c439859995910a20e38b86f00"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58017 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which leads to undefined behavior. To prevent this, cast 1 to u32 before performing the shift, ensuring well-defined behavior. This change explicitly avoids any potential overflow by ensuring that the shift occurs on an unsigned 32-bit integer. | ["https://git.kernel.org/stable/c/3d6f83df8ff2d5de84b50377e4f0d45e25311c7a","https://git.kernel.org/stable/c/404e5fd918a0b14abec06c7eca128f04c9b98e41","https://git.kernel.org/stable/c/4a2c4e7265b8eed83c25d86d702cea06493cab18","https://git.kernel.org/stable/c/4acf6bab775dbd22a9a799030a808a7305e01d63","https://git.kernel.org/stable/c/54c14022fa2ba427dc543455c2cf9225903a7174","https://git.kernel.org/stable/c/9a6d43844de2479a3ff8d674c3e2a16172e01598","https://git.kernel.org/stable/c/bb8ff054e19fe27f4e5eaac1b05e462894cfe9b1","https://git.kernel.org/stable/c/dfb7b179741ee09506dc7719d92f9e1cea01f10e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21848 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfp: bpf: Add check for nfp_app_ctrl_msg_alloc() Add check for the return value of nfp_app_ctrl_msg_alloc() in nfp_bpf_cmsg_alloc() to prevent null pointer dereference. | ["https://git.kernel.org/stable/c/1358d8e07afdf21d49ca6f00c56048442977e00a","https://git.kernel.org/stable/c/29ccb1e4040da6ff02b7e64efaa2f8e6bf06020d","https://git.kernel.org/stable/c/878e7b11736e062514e58f3b445ff343e6705537","https://git.kernel.org/stable/c/897c32cd763fd11d0b6ed024c52f44d2475bb820","https://git.kernel.org/stable/c/924b239f9704566e0d86abd894d2d64bd73c11eb","https://git.kernel.org/stable/c/bd97f60750bb581f07051f98e31dfda59d3a783b","https://git.kernel.org/stable/c/d64c6ca420019712e194fe095b55f87363e22a9a","https://git.kernel.org/stable/c/e976ea6c5e1b005c64467cbf94a8577aae9c7d81"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21862 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drop_monitor: fix incorrect initialization order Syzkaller reports the following bug: BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7 RIP: 0033:0x7f3f9815aee9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9 RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007 RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768 If drop_monitor is built as a kernel module, syzkaller may have time to send a netlink NET_DM_CMD_START message during the module loading. This will call the net_dm_monitor_start() function that uses a spinlock that has not yet been initialized. To fix this, let's place resource initialization above the registration of a generic netlink family. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/07b598c0e6f06a0f254c88dafb4ad50f8a8c6eea","https://git.kernel.org/stable/c/0efa6c42f81c60d8f72ba7f5ed8d4fec8c526282","https://git.kernel.org/stable/c/219a47d0e6195bd202f22855e35f25bd15bc4d58","https://git.kernel.org/stable/c/29f9cdcab3d96d5207a5c92b52c40ad75e5915d8","https://git.kernel.org/stable/c/6e9e0f224ffd8b819da3ea247dda404795fdd182","https://git.kernel.org/stable/c/872c7c7e57a746046796ddfead529c9d37b9f6b4","https://git.kernel.org/stable/c/b7859e8643e75619b2705b4fcac93ffd94d72b4a","https://git.kernel.org/stable/c/fcfc00bfec7bb6661074cb21356d05a4c9470a3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46742 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open() null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE) and parse_lease_state() return NULL. Fix this by check if 'lease_ctx_info' is NULL. Additionally, remove the redundant parentheses in parse_durable_handle_context(). | ["https://git.kernel.org/stable/c/07f384c5be1f8633b13f0a22616e227570450bc6","https://git.kernel.org/stable/c/3b692794b81f2ecad69a4adbba687f3836824ada","https://git.kernel.org/stable/c/4e8771a3666c8f216eefd6bd2fd50121c6c437db","https://git.kernel.org/stable/c/878f32878351104448b86ef5b85d1f8ed6f599fb","https://git.kernel.org/stable/c/ec28c35029b7930f31117f9284874b63bea4f31b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57913 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Remove WARN_ON in functionfs_bind This commit addresses an issue related to below kernel panic where panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON in functionsfs_bind, which easily leads to the following scenarios. 1.adb_write in adbd 2. UDC write via configfs ================= ===================== ->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register() ->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() <times-out without BIND event> ->configfs_composite_bind() ->usb_add_function() ->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() <ffs->state !=FFS_ACTIVE> The adb_open, adb_read, and adb_write operations are invoked from the daemon, but trying to bind the function is a process that is invoked by UDC write through configfs, which opens up the possibility of a race condition between the two paths. In this race scenario, the kernel panic occurs due to the WARN_ON from functionfs_bind when panic_on_warn is enabled. This commit fixes the kernel panic by removing the unnecessary WARN_ON. Kernel panic - not syncing: kernel: panic_on_warn set ... [ 14.542395] Call trace: [ 14.542464] ffs_func_bind+0x1c8/0x14a8 [ 14.542468] usb_add_function+0xcc/0x1f0 [ 14.542473] configfs_composite_bind+0x468/0x588 [ 14.542478] gadget_bind_driver+0x108/0x27c [ 14.542483] really_probe+0x190/0x374 [ 14.542488] __driver_probe_device+0xa0/0x12c [ 14.542492] driver_probe_device+0x3c/0x220 [ 14.542498] __driver_attach+0x11c/0x1fc [ 14.542502] bus_for_each_dev+0x104/0x160 [ 14.542506] driver_attach+0x24/0x34 [ 14.542510] bus_add_driver+0x154/0x270 [ 14.542514] driver_register+0x68/0x104 [ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4 [ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144 [ 14.542526] configfs_write_iter+0xf0/0x138 | ["https://git.kernel.org/stable/c/19fc1c83454ca9d5699e39633ec79ce26355251c","https://git.kernel.org/stable/c/3e4d32cc145955d5c56c5498a3ff057e4aafa9d1","https://git.kernel.org/stable/c/82f60f3600aecd9ffcd0fbc4e193694511c85b47","https://git.kernel.org/stable/c/a8b6a18b9b66cc4c016d63132b59ce5383f7cdd2","https://git.kernel.org/stable/c/bfe60030fcd976e3546e1f73d6d0eb3fea26442e","https://git.kernel.org/stable/c/dfc51e48bca475bbee984e90f33fdc537ce09699","https://git.kernel.org/stable/c/ea6a1498742430eb2effce0d1439ff29ef37dd7d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2196 | High | fixed |
|
A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn't need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5","https://kernel.dance/#2e7eab81425a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e7eab81425ad6c875f2ed47c0ce01e78afc38a5","https://kernel.dance/#2e7eab81425a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230223-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48948 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Prevent buffer overflow in setup handler Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req->actual bytes to uvc_event->data.data array of size 60. This may result in an overflow of 4 bytes. | ["https://git.kernel.org/stable/c/06fd17ee92c8f1704c7e54ec0fd50ae0542a49a5","https://git.kernel.org/stable/c/4972e3528b968665b596b5434764ff8fd9446d35","https://git.kernel.org/stable/c/4c92670b16727365699fe4b19ed32013bab2c107","https://git.kernel.org/stable/c/6b41a35b41f77821db24f2d8f66794b390a585c5","https://git.kernel.org/stable/c/7b1f773277a72f9756d47a41b94e43506cce1954","https://git.kernel.org/stable/c/b8fb1cba934ea122b50f13a4f9d6fc4fdc43d2be","https://git.kernel.org/stable/c/bc8380fe5768c564f921f7b4eaba932e330b9e4b","https://git.kernel.org/stable/c/c79538f32df12887f110dcd6b9c825b482905f24","https://git.kernel.org/stable/c/d1a92bb8d697f170d93fe922da763d7d156b8841"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56615 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: fix OOB devmap writes when deleting elements Jordy reported issue against XSKMAP which also applies to DEVMAP - the index used for accessing map entry, due to being a signed integer, causes the OOB writes. Fix is simple as changing the type from int to u32, however, when compared to XSKMAP case, one more thing needs to be addressed. When map is released from system via dev_map_free(), we iterate through all of the entries and an iterator variable is also an int, which implies OOB accesses. Again, change it to be u32. Example splat below: [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000 [ 160.731662] #PF: supervisor read access in kernel mode [ 160.736876] #PF: error_code(0x0000) - not-present page [ 160.742095] PGD 0 P4D 0 [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487 [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170 [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202 [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024 [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000 [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001 [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122 [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000 [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000 [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0 [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 160.874092] PKRU: 55555554 [ 160.876847] Call Trace: [ 160.879338] <TASK> [ 160.881477] ? __die+0x20/0x60 [ 160.884586] ? page_fault_oops+0x15a/0x450 [ 160.888746] ? search_extable+0x22/0x30 [ 160.892647] ? search_bpf_extables+0x5f/0x80 [ 160.896988] ? exc_page_fault+0xa9/0x140 [ 160.900973] ? asm_exc_page_fault+0x22/0x30 [ 160.905232] ? dev_map_free+0x77/0x170 [ 160.909043] ? dev_map_free+0x58/0x170 [ 160.912857] bpf_map_free_deferred+0x51/0x90 [ 160.917196] process_one_work+0x142/0x370 [ 160.921272] worker_thread+0x29e/0x3b0 [ 160.925082] ? rescuer_thread+0x4b0/0x4b0 [ 160.929157] kthread+0xd4/0x110 [ 160.932355] ? kthread_park+0x80/0x80 [ 160.936079] ret_from_fork+0x2d/0x50 [ 160.943396] ? kthread_park+0x80/0x80 [ 160.950803] ret_from_fork_asm+0x11/0x20 [ 160.958482] </TASK> | ["https://git.kernel.org/stable/c/0f170e91d3063ca60baec4bd9f544faf3bfe29eb","https://git.kernel.org/stable/c/178e31df1fb3d9e0890eb471da16709cbc82edee","https://git.kernel.org/stable/c/70f3de869865f9c3da0508a5ea29f6f4c1889057","https://git.kernel.org/stable/c/8e858930695d3ebec423e85384c95427258c294f","https://git.kernel.org/stable/c/98c03d05936d846073df8f550e9e8bf0dde1d77f","https://git.kernel.org/stable/c/ab244dd7cf4c291f82faacdc50b45cc0f55b674d","https://git.kernel.org/stable/c/ad34306ac6836e5dd096b7d0ad4aa20cb7c8d9e5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56693 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: brd: defer automatic disk creation until module initialization succeeds My colleague Wupeng found the following problems during fault injection: BUG: unable to handle page fault for address: fffffbfff809d073 PGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:__asan_load8+0x4c/0xa0 ... Call Trace: <TASK> blkdev_put_whole+0x41/0x70 bdev_release+0x1a3/0x250 blkdev_release+0x11/0x20 __fput+0x1d7/0x4a0 task_work_run+0xfc/0x180 syscall_exit_to_user_mode+0x1de/0x1f0 do_syscall_64+0x6b/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e loop_init() is calling loop_add() after __register_blkdev() succeeds and is ignoring disk_add() failure from loop_add(), for loop_add() failure is not fatal and successfully created disks are already visible to bdev_open(). brd_init() is currently calling brd_alloc() before __register_blkdev() succeeds and is releasing successfully created disks when brd_init() returns an error. This can cause UAF for the latter two case: case 1: T1: modprobe brd brd_init brd_alloc(0) // success add_disk disk_scan_partitions bdev_file_open_by_dev // alloc file fput // won't free until back to userspace brd_alloc(1) // failed since mem alloc error inject // error path for modprobe will release code segment // back to userspace __fput blkdev_release bdev_release blkdev_put_whole bdev->bd_disk->fops->release // fops is freed now, UAF! case 2: T1: T2: modprobe brd brd_init brd_alloc(0) // success open(/dev/ram0) brd_alloc(1) // fail // error path for modprobe close(/dev/ram0) ... /* UAF! */ bdev->bd_disk->fops->release Fix this problem by following what loop_init() does. Besides, reintroduce brd_devices_mutex to help serialize modifications to brd_list. | ["https://git.kernel.org/stable/c/259bf925583ec9e3781df778cadf00594095090d","https://git.kernel.org/stable/c/410896624db639500f24f46478b4bfa05c76bf56","https://git.kernel.org/stable/c/41219c147df8bbd6591f59af5d695fb6c9a1cbff","https://git.kernel.org/stable/c/63dfd728b30f79495dacc886127695a379805152","https://git.kernel.org/stable/c/826cc42adf44930a633d11a5993676d85ddb0842","https://git.kernel.org/stable/c/c0c2744cd2939ec5999c51dbaf2af16886548b7b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52494 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Add alignment check for event ring read pointer Though we do check the event ring read pointer by "is_valid_ring_ptr" to make sure it is in the buffer range, but there is another risk the pointer may be not aligned. Since we are expecting event ring elements are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer could lead to multiple issues like DoS or ring buffer memory corruption. So add a alignment check for event ring read pointer. | ["https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551","https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08","https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010","https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b","https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f","https://git.kernel.org/stable/c/2df39ac8f813860f79782807c3f7acff40b3c551","https://git.kernel.org/stable/c/94991728c84f8df54fd9eec9b85855ef9057ea08","https://git.kernel.org/stable/c/a9ebfc405fe1be145f414eafadcbf09506082010","https://git.kernel.org/stable/c/ecf8320111822a1ae5d5fc512953eab46d543d0b","https://git.kernel.org/stable/c/eff9704f5332a13b08fbdbe0f84059c9e7051d5f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4207 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation. When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit 76e42ae831991c828cffa8c37736ebfb831ad5ec. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec","https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76e42ae831991c828cffa8c37736ebfb831ad5ec","https://kernel.dance/76e42ae831991c828cffa8c37736ebfb831ad5ec","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52737 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: lock the inode in shared mode before starting fiemap Currently fiemap does not take the inode's lock (VFS lock), it only locks a file range in the inode's io tree. This however can lead to a deadlock if we have a concurrent fsync on the file and fiemap code triggers a fault when accessing the user space buffer with fiemap_fill_next_extent(). The deadlock happens on the inode's i_mmap_lock semaphore, which is taken both by fsync and btrfs_page_mkwrite(). This deadlock was recently reported by syzbot and triggers a trace like the following: task:syz-executor361 state:D stack:20264 pid:5668 ppid:5119 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 wait_on_state fs/btrfs/extent-io-tree.c:707 [inline] wait_extent_bit+0x577/0x6f0 fs/btrfs/extent-io-tree.c:751 lock_extent+0x1c2/0x280 fs/btrfs/extent-io-tree.c:1742 find_lock_delalloc_range+0x4e6/0x9c0 fs/btrfs/extent_io.c:488 writepage_delalloc+0x1ef/0x540 fs/btrfs/extent_io.c:1863 __extent_writepage+0x736/0x14e0 fs/btrfs/extent_io.c:2174 extent_write_cache_pages+0x983/0x1220 fs/btrfs/extent_io.c:3091 extent_writepages+0x219/0x540 fs/btrfs/extent_io.c:3211 do_writepages+0x3c3/0x680 mm/page-writeback.c:2581 filemap_fdatawrite_wbc+0x11e/0x170 mm/filemap.c:388 __filemap_fdatawrite_range mm/filemap.c:421 [inline] filemap_fdatawrite_range+0x175/0x200 mm/filemap.c:439 btrfs_fdatawrite_range fs/btrfs/file.c:3850 [inline] start_ordered_ops fs/btrfs/file.c:1737 [inline] btrfs_sync_file+0x4ff/0x1190 fs/btrfs/file.c:1839 generic_write_sync include/linux/fs.h:2885 [inline] btrfs_do_write_iter+0xcd3/0x1280 fs/btrfs/file.c:1684 call_write_iter include/linux/fs.h:2189 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f7d4054e9b9 RSP: 002b:00007f7d404fa2f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007f7d405d87a0 RCX: 00007f7d4054e9b9 RDX: 0000000000000090 RSI: 0000000020000000 RDI: 0000000000000006 RBP: 00007f7d405a51d0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 61635f65646f6e69 R13: 65646f7475616f6e R14: 7261637369646f6e R15: 00007f7d405d87a8 </TASK> INFO: task syz-executor361:5697 blocked for more than 145 seconds. Not tainted 6.2.0-rc3-syzkaller-00376-g7c6984405241 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:syz-executor361 state:D stack:21216 pid:5697 ppid:5119 flags:0x00004004 Call Trace: <TASK> context_switch kernel/sched/core.c:5293 [inline] __schedule+0x995/0xe20 kernel/sched/core.c:6606 schedule+0xcb/0x190 kernel/sched/core.c:6682 rwsem_down_read_slowpath+0x5f9/0x930 kernel/locking/rwsem.c:1095 __down_read_common+0x54/0x2a0 kernel/locking/rwsem.c:1260 btrfs_page_mkwrite+0x417/0xc80 fs/btrfs/inode.c:8526 do_page_mkwrite+0x19e/0x5e0 mm/memory.c:2947 wp_page_shared+0x15e/0x380 mm/memory.c:3295 handle_pte_fault mm/memory.c:4949 [inline] __handle_mm_fault mm/memory.c:5073 [inline] handle_mm_fault+0x1b79/0x26b0 mm/memory.c:5219 do_user_addr_fault+0x69b/0xcb0 arch/x86/mm/fault.c:1428 handle_page_fault arch/x86/mm/fault.c:1519 [inline] exc_page_fault+0x7a/0x110 arch/x86/mm/fault.c:1575 asm_exc_page_fault+0x22/0x30 arch/x86/include/asm/idtentry.h:570 RIP: 0010:copy_user_short_string+0xd/0x40 arch/x86/lib/copy_user_64.S:233 Code: 74 0a 89 (...) RSP: 0018:ffffc9000570f330 EFLAGS: 000502 ---truncated--- | ["https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508","https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1","https://git.kernel.org/stable/c/519b7e13b5ae8dd38da1e52275705343be6bb508","https://git.kernel.org/stable/c/d8c594da79bc0244e610a70594e824a401802be1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56770 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: netem: account for backlog updates from child qdisc In general, 'qlen' of any classful qdisc should keep track of the number of packets that the qdisc itself and all of its children holds. In case of netem, 'qlen' only accounts for the packets in its internal tfifo. When netem is used with a child qdisc, the child qdisc can use 'qdisc_tree_reduce_backlog' to inform its parent, netem, about created or dropped SKBs. This function updates 'qlen' and the backlog statistics of netem, but netem does not account for changes made by a child qdisc. 'qlen' then indicates the wrong number of packets in the tfifo. If a child qdisc creates new SKBs during enqueue and informs its parent about this, netem's 'qlen' value is increased. When netem dequeues the newly created SKBs from the child, the 'qlen' in netem is not updated. If 'qlen' reaches the configured sch->limit, the enqueue function stops working, even though the tfifo is not full. Reproduce the bug: Ensure that the sender machine has GSO enabled. Configure netem as root qdisc and tbf as its child on the outgoing interface of the machine as follows: $ tc qdisc add dev <oif> root handle 1: netem delay 100ms limit 100 $ tc qdisc add dev <oif> parent 1:0 tbf rate 50Mbit burst 1542 latency 50ms Send bulk TCP traffic out via this interface, e.g., by running an iPerf3 client on the machine. Check the qdisc statistics: $ tc -s qdisc show dev <oif> Statistics after 10s of iPerf3 TCP test before the fix (note that netem's backlog > limit, netem stopped accepting packets): qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 2767766 bytes 1848 pkt (dropped 652, overlimits 0 requeues 0) backlog 4294528236b 1155p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 2767766 bytes 1848 pkt (dropped 327, overlimits 7601 requeues 0) backlog 0b 0p requeues 0 Statistics after the fix: qdisc netem 1: root refcnt 2 limit 1000 delay 100ms Sent 37766372 bytes 24974 pkt (dropped 9, overlimits 0 requeues 0) backlog 0b 0p requeues 0 qdisc tbf 10: parent 1:1 rate 50Mbit burst 1537b lat 50ms Sent 37766372 bytes 24974 pkt (dropped 327, overlimits 96017 requeues 0) backlog 0b 0p requeues 0 tbf segments the GSO SKBs (tbf_segment) and updates the netem's 'qlen'. The interface fully stops transferring packets and "locks". In this case, the child qdisc and tfifo are empty, but 'qlen' indicates the tfifo is at its limit and no more packets are accepted. This patch adds a counter for the entries in the tfifo. Netem's 'qlen' is only decreased when a packet is returned by its dequeue function, and not during enqueuing into the child qdisc. External updates to 'qlen' are thus accounted for and only the behavior of the backlog statistics changes. As in other qdiscs, 'qlen' then keeps track of how many packets are held in netem and all of its children. As before, sch->limit remains as the maximum number of packets in the tfifo. The same applies to netem's backlog statistics. | ["https://git.kernel.org/stable/c/10df49cfca73dfbbdb6c4150d859f7e8926ae427","https://git.kernel.org/stable/c/216509dda290f6db92c816dd54b83c1df9da9e76","https://git.kernel.org/stable/c/356078a5c55ec8d2061fcc009fb8599f5b0527f9","https://git.kernel.org/stable/c/3824c5fad18eeb7abe0c4fc966f29959552dca3e","https://git.kernel.org/stable/c/83c6ab12f08dcc09d4c5ac86fdb89736b28f1d31","https://git.kernel.org/stable/c/c2047b0e216c8edce227d7c42f99ac2877dad0e4","https://git.kernel.org/stable/c/f8d4bc455047cf3903cd6f85f49978987dbb3027"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42064 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip pipe if the pipe idx not set properly [why] Driver crashes when pipe idx not set properly [how] Add code to skip the pipe that idx not set properly | ["https://git.kernel.org/stable/c/27df59c6071470efce7182ee92fbb16afba551e0","https://git.kernel.org/stable/c/af114efe8d24b5711cfbedf7180f2ac1a296c24b","https://git.kernel.org/stable/c/27df59c6071470efce7182ee92fbb16afba551e0","https://git.kernel.org/stable/c/af114efe8d24b5711cfbedf7180f2ac1a296c24b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42065 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Add a NULL check in xe_ttm_stolen_mgr_init Add an explicit check to ensure that the mgr is not NULL. | ["https://git.kernel.org/stable/c/a6eff8f9c7e844cb24ccb188ca24abcd59734e74","https://git.kernel.org/stable/c/cc796a77985d6af75c9362cb2e73dce4ae3f97cd","https://git.kernel.org/stable/c/a6eff8f9c7e844cb24ccb188ca24abcd59734e74","https://git.kernel.org/stable/c/cc796a77985d6af75c9362cb2e73dce4ae3f97cd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42066 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix potential integer overflow in page size calculation Explicitly cast tbo->page_alignment to u64 before bit-shifting to prevent overflow when assigning to min_page_size. | ["https://git.kernel.org/stable/c/4f4fcafde343a54465f85a2909fc684918507a4b","https://git.kernel.org/stable/c/79d54ddf0e292b810887994bb04709c5ac0e1531","https://git.kernel.org/stable/c/4f4fcafde343a54465f85a2909fc684918507a4b","https://git.kernel.org/stable/c/79d54ddf0e292b810887994bb04709c5ac0e1531"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42078 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: initialise nfsd_info.mutex early. nfsd_info.mutex can be dereferenced by svc_pool_stats_start() immediately after the new netns is created. Currently this can trigger an oops. Move the initialisation earlier before it can possibly be dereferenced. | ["https://git.kernel.org/stable/c/7e8b94045bc77ce4f085ddfb9eb04e5760e66169","https://git.kernel.org/stable/c/e0011bca603c101f2a3c007bdb77f7006fa78fb1","https://git.kernel.org/stable/c/7e8b94045bc77ce4f085ddfb9eb04e5760e66169","https://git.kernel.org/stable/c/e0011bca603c101f2a3c007bdb77f7006fa78fb1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42081 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe/xe_devcoredump: Check NULL before assignments Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) | ["https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37","https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a","https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37","https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42083 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ionic: fix kernel panic due to multi-buffer handling Currently, the ionic_run_xdp() doesn't handle multi-buffer packets properly for XDP_TX and XDP_REDIRECT. When a jumbo frame is received, the ionic_run_xdp() first makes xdp frame with all necessary pages in the rx descriptor. And if the action is either XDP_TX or XDP_REDIRECT, it should unmap dma-mapping and reset page pointer to NULL for all pages, not only the first page. But it doesn't for SG pages. So, SG pages unexpectedly will be reused. It eventually causes kernel panic. Oops: general protection fault, probably for non-canonical address 0x504f4e4dbebc64ff: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.10.0-rc3+ #25 RIP: 0010:xdp_return_frame+0x42/0x90 Code: 01 75 12 5b 4c 89 e6 5d 31 c9 41 5c 31 d2 41 5d e9 73 fd ff ff 44 8b 6b 20 0f b7 43 0a 49 81 ed 68 01 00 00 49 29 c5 49 01 fd <41> 80 7d0 RSP: 0018:ffff99d00122ce08 EFLAGS: 00010202 RAX: 0000000000005453 RBX: ffff8d325f904000 RCX: 0000000000000001 RDX: 00000000670e1000 RSI: 000000011f90d000 RDI: 504f4e4d4c4b4a49 RBP: ffff99d003907740 R08: 0000000000000000 R09: 0000000000000000 R10: 000000011f90d000 R11: 0000000000000000 R12: ffff8d325f904010 R13: 504f4e4dbebc64fd R14: ffff8d3242b070c8 R15: ffff99d0039077c0 FS: 0000000000000000(0000) GS:ffff8d399f780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f41f6c85e38 CR3: 000000037ac30000 CR4: 00000000007506f0 PKRU: 55555554 Call Trace: <IRQ> ? die_addr+0x33/0x90 ? exc_general_protection+0x251/0x2f0 ? asm_exc_general_protection+0x22/0x30 ? xdp_return_frame+0x42/0x90 ionic_tx_clean+0x211/0x280 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] ionic_tx_cq_service+0xd3/0x210 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] ionic_txrx_napi+0x41/0x1b0 [ionic 15881354510e6a9c655c59c54812b319ed2cd015] __napi_poll.constprop.0+0x29/0x1b0 net_rx_action+0x2c4/0x350 handle_softirqs+0xf4/0x320 irq_exit_rcu+0x78/0xa0 common_interrupt+0x77/0x90 | ["https://git.kernel.org/stable/c/8ae401525ae84228a8986bb369224a6224e4d22f","https://git.kernel.org/stable/c/e3f02f32a05009a688a87f5799e049ed6b55bab5","https://git.kernel.org/stable/c/8ae401525ae84228a8986bb369224a6224e4d22f","https://git.kernel.org/stable/c/e3f02f32a05009a688a87f5799e049ed6b55bab5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42134 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: virtio-pci: Check if is_avq is NULL [bug] In the virtio_pci_common.c function vp_del_vqs, vp_dev->is_avq is involved to determine whether it is admin virtqueue, but this function vp_dev->is_avq may be empty. For installations, virtio_pci_legacy does not assign a value to vp_dev->is_avq. [fix] Check whether it is vp_dev->is_avq before use. [test] Test with virsh Attach device Before this patch, the following command would crash the guest system After applying the patch, everything seems to be working fine. | ["https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106","https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d94252824498","https://git.kernel.org/stable/c/5e2024b0b9b3d5709e3f7e9b92951d7e29154106","https://git.kernel.org/stable/c/c8fae27d141a32a1624d0d0d5419d94252824498"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42151 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable Test case dummy_st_ops/dummy_init_ret_value passes NULL as the first parameter of the test_1() function. Mark this parameter as nullable to make verifier aware of such possibility. Otherwise, NULL check in the test_1() code: SEC("struct_ops/test_1") int BPF_PROG(test_1, struct bpf_dummy_ops_state *state) { if (!state) return ...; ... access state ... } Might be removed by verifier, thus triggering NULL pointer dereference under certain conditions. | ["https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d","https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23","https://git.kernel.org/stable/c/1479eaff1f16983d8fda7c5a08a586c21891087d","https://git.kernel.org/stable/c/7f79097b0de97a486b137b750d7dd7b20b519d23"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39468 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix deadlock in smb2_find_smb_tcon() Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such deadlock. | ["https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15","https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720","https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a","https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47","https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261","https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5","https://git.kernel.org/stable/c/02c418774f76a0a36a6195c9dbf8971eb4130a15","https://git.kernel.org/stable/c/21f5dd36e655d25a7b45b61c1e537198b671f720","https://git.kernel.org/stable/c/225de871ddf994f69a57f035709cad9c0ab8615a","https://git.kernel.org/stable/c/8d0f5f1ccf675454a833a573c53830a49b7d1a47","https://git.kernel.org/stable/c/b055752675cd1d1db4ac9c2750db3dc3e89ea261","https://git.kernel.org/stable/c/b09b556e48968317887a11243a5331a7bc00ece5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48718 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: mxsfb: Fix NULL pointer dereference mxsfb should not ever dereference the NULL pointer which drm_atomic_get_new_bridge_state is allowed to return. Assume a fixed format instead. | ["https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64","https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4","https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1","https://git.kernel.org/stable/c/622c9a3a7868e1eeca39c55305ca3ebec4742b64","https://git.kernel.org/stable/c/6f9267e01cca749137349d8ffb0d0ebbadf567f4","https://git.kernel.org/stable/c/86a337bb803040e4401b87c974a7fb92efe3d0e1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52744 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix potential NULL-ptr-dereference in_dev_get() can return NULL which will cause a failure once idev is dereferenced in in_dev_for_each_ifa_rtnl(). This patch adds a check for NULL value in idev beforehand. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d","https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e","https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f","https://git.kernel.org/stable/c/360682fe7df262d94fae54f737c487bec0f9190d","https://git.kernel.org/stable/c/5d9745cead1f121974322b94ceadfb4d1e67960e","https://git.kernel.org/stable/c/8f5fe1cd8e6a97f94840b55f59ed08cbc397086f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35945 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: phy_device: Prevent nullptr exceptions on ISR If phydev->irq is set unconditionally, check for valid interrupt handler or fall back to polling mode to prevent nullptr exceptions in interrupt service routine. | ["https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311","https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b","https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5","https://git.kernel.org/stable/c/3419ee39e3d3162ab2ec9942bb537613ed5b6311","https://git.kernel.org/stable/c/61c81872815f46006982bb80460c0c80a949b35b","https://git.kernel.org/stable/c/7a71f61ebf95cedd3f245db6da397822971d8db5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35946 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: fix null pointer access when abort scan During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif. | ["https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d","https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2","https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8","https://git.kernel.org/stable/c/4f11c741908dab7dd48fa5a986b210d4fc74ca8d","https://git.kernel.org/stable/c/7e11a2966f51695c0af0b1f976a32d64dee243b2","https://git.kernel.org/stable/c/b34d64e9aa5505e3c84570aed5c757f1839573e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35972 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible memory leak in bnxt_rdma_aux_device_init() If ulp = kzalloc() fails, the allocated edev will leak because it is not properly assigned and the cleanup path will not be able to free it. Fix it by assigning it properly immediately after allocation. | ["https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe","https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff","https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004","https://git.kernel.org/stable/c/10a9d6a7513f93d7faffcb341af0aa42be8218fe","https://git.kernel.org/stable/c/7ac10c7d728d75bc9daaa8fade3c7a3273b9a9ff","https://git.kernel.org/stable/c/c60ed825530b8c0cc2b524efd39b1d696ec54004"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38625 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check 'folio' pointer for NULL It can be NULL if bmap is called. | ["https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803","https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8","https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641","https://git.kernel.org/stable/c/1cd6c96219c429ebcfa8e79a865277376c563803","https://git.kernel.org/stable/c/6c8054d590668629bb2eb6fb4cbf22455d08ada8","https://git.kernel.org/stable/c/ff1068929459347f9e47f8d14c409dcf938c2641"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3359 | Medium | fixed |
|
An issue was discovered in the Linux kernel brcm_nvram_parse in drivers/nvmem/brcm_nvram.c. Lacks for the check of the return value of kzalloc() can cause the NULL Pointer Dereference. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0576ade3aaf24b376ea1a4406ae138e2a22b0c0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b0576ade3aaf24b376ea1a4406ae138e2a22b0c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48978 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: core: fix shift-out-of-bounds in hid_report_raw_event Syzbot reported shift-out-of-bounds in hid_report_raw_event. microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) > 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type 'int' CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322 snto32 drivers/hid/hid-core.c:1323 [inline] hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline] hid_process_report drivers/hid/hid-core.c:1665 [inline] hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998 hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066 hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284 __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671 dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988 call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474 expire_timers kernel/time/timer.c:1519 [inline] __run_timers+0x76a/0x980 kernel/time/timer.c:1790 run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803 __do_softirq+0x277/0x75b kernel/softirq.c:571 __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650 irq_exit_rcu+0x5/0x20 kernel/softirq.c:662 sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ====================================================================== If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type 'int', resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32. | ["https://git.kernel.org/stable/c/151493fe5a6ed1a88decc929a7368a3f2a246914","https://git.kernel.org/stable/c/2b3b4d7aadaa1b6b58d0f34823bf86cfe8a31b4d","https://git.kernel.org/stable/c/809783f8b4b600c7fb3bccb10fefef822601ea3b","https://git.kernel.org/stable/c/8e14f20e12224ee2429f75a5c9418a700e26a8d3","https://git.kernel.org/stable/c/bc03f809da78fc79e4aee132d4e5c6a2b3aeec73","https://git.kernel.org/stable/c/db1ed1b3fb4ec0d19080a102956255769bc45c79","https://git.kernel.org/stable/c/ec61b41918587be530398b0d1c9a0d16619397e5","https://git.kernel.org/stable/c/f755d11c55b29049b77da5cd9ab2faae96eb33c3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49007 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() Syzbot reported a null-ptr-deref bug: NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 3603 Comm: segctord Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 fs/nilfs2/alloc.c:608 Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 Call Trace: <TASK> nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> ... If DAT metadata file is corrupted on disk, there is a case where req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during a b-tree operation that cascadingly updates ancestor nodes of the b-tree, because nilfs_dat_commit_alloc() for a lower level block can initialize the blocknr on the same DAT entry between nilfs_dat_prepare_end() and nilfs_dat_commit_end(). If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and causes the NULL pointer dereference above in nilfs_palloc_commit_free_entry() function, which leads to a crash. Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). This also calls nilfs_error() in that case to notify that there is a fatal flaw in the filesystem metadata and prevent further operations. | ["https://git.kernel.org/stable/c/165c7a3b27a3857ebf57f626b9f38b48b6792e68","https://git.kernel.org/stable/c/2f2c59506ae39496588ceb8b88bdbdbaed895d63","https://git.kernel.org/stable/c/33021419fd81efd3d729a7f19341ba4b98fe66ce","https://git.kernel.org/stable/c/381b84f60e549ea98cec4666c6c728b1b3318756","https://git.kernel.org/stable/c/9a130b72e6bd1fb07fc3cde839dc6fb53da76f07","https://git.kernel.org/stable/c/bc3fd3293887b4cf84a9109700faeb82de533c89","https://git.kernel.org/stable/c/e858917ab785afe83c14f5ac141301216ccda847","https://git.kernel.org/stable/c/f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49021 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: fix null-ptr-deref while probe() failed I got a null-ptr-deref report as following when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G B N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace: <TASK> klist_remove+0xf1/0x1c0 device_release_driver_internal+0x23e/0x2d0 bus_remove_device+0x1bd/0x240 device_del+0x357/0x770 phy_device_remove+0x11/0x30 mdiobus_unregister+0xa5/0x140 release_nodes+0x6a/0xa0 devres_release_all+0xf8/0x150 device_unbind_cleanup+0x19/0xd0 //probe path: phy_device_register() device_add() phy_connect phy_attach_direct() //set device driver probe() //it's failed, driver is not bound device_bind_driver() // probe failed, it's not called //remove path: phy_device_remove() device_del() device_release_driver_internal() __device_release_driver() //dev->drv is not NULL klist_remove() <- knode_driver is not added yet, cause null-ptr-deref In phy_attach_direct(), after setting the 'dev->driver', probe() fails, device_bind_driver() is not called, so the knode_driver->n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev->driver to NULL in the error path in phy_attach_direct(). | ["https://git.kernel.org/stable/c/0744c7be4de564db03e24527b2e096b7e0e20972","https://git.kernel.org/stable/c/369eb2c9f1f72adbe91e0ea8efb130f0a2ba11a6","https://git.kernel.org/stable/c/3e21f85d87c836462bb52ef2078ea561260935c1","https://git.kernel.org/stable/c/51d7f6b20fae8bae64ad1136f1e30d1fd5ba78f7","https://git.kernel.org/stable/c/7730904f50c7187dd16c76949efb56b5fb55cd57","https://git.kernel.org/stable/c/8aaafe0f71314f46a066382a047ba8bb3840d273","https://git.kernel.org/stable/c/eaa5722549ac2604ffa56c2e946acc83226f130c","https://git.kernel.org/stable/c/fe6bc99c27c21348f548966118867ed26a9a372c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49033 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit() Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80 Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item in btrfs_run_qgroups() later outside of the spinlock context. | ["https://git.kernel.org/stable/c/01d7c41eac9129fba80d8aed0060caab4a7dbe09","https://git.kernel.org/stable/c/044da1a371a0da579e805e89c96865f62d8f6f69","https://git.kernel.org/stable/c/3c98e91be6aea4c7acf09da6eb0c107ea9186bb5","https://git.kernel.org/stable/c/588ae4fdd8b11788a797776b10d6c44ae12bc133","https://git.kernel.org/stable/c/89840b12c8fad7200eb6478525c13261512c01be","https://git.kernel.org/stable/c/8eb912af525042a7365295eb62f6d5270c2a6462","https://git.kernel.org/stable/c/f4b930a1602b05e77fee31f9616599b25e910a86","https://git.kernel.org/stable/c/f7e942b5bb35d8e3af54053d19a6bf04143a3955"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: sdata can be NULL during AMPDU start ieee80211_tx_ba_session_handle_start() may get NULL for sdata when a deauthentication is ongoing. Here a trace triggering the race with the hostapd test multi_ap_fronthaul_on_ap: (gdb) list *drv_ampdu_action+0x46 0x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396). 391 int ret = -EOPNOTSUPP; 392 393 might_sleep(); 394 395 sdata = get_bss_sdata(sdata); 396 if (!check_sdata_in_driver(sdata)) 397 return -EIO; 398 399 trace_drv_ampdu_action(local, sdata, params); 400 wlan0: moving STA 02:00:00:00:03:00 to state 3 wlan0: associated wlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING) wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0 wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port) wlan0: moving STA 02:00:00:00:03:00 to state 2 wlan0: moving STA 02:00:00:00:03:00 to state 1 wlan0: Removed STA 02:00:00:00:03:00 wlan0: Destroyed STA 02:00:00:00:03:00 BUG: unable to handle page fault for address: fffffffffffffb48 PGD 11814067 P4D 11814067 PUD 11816067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G W 6.1.0-rc8-wt+ #59 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014 Workqueue: phy3 ieee80211_ba_session_work [mac80211] RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211] Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 <8b> 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85 RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287 RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240 RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40 RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0 R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8 FS: 0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0 Call Trace: <TASK> ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> | ["https://git.kernel.org/stable/c/187523fa7c2d4c780f775cb869216865c4a909ef","https://git.kernel.org/stable/c/69403bad97aa0162e3d7911b27e25abe774093df","https://git.kernel.org/stable/c/a12fd43bd175fa52c82f9740179d38c34ca1b62e","https://git.kernel.org/stable/c/c838df8461a601b20dc1b9fb1834d2aad8e2f949"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Prevent release of buffer in I/O When a task waiting for completion of a Store Data operation is interrupted, an attempt is made to halt this operation. If this attempt fails due to a hardware or firmware problem, there is a chance that the SCLP facility might store data into buffers referenced by the original operation at a later time. Handle this situation by not releasing the referenced data buffers if the halt attempt fails. For current use cases, this might result in a leak of few pages of memory in case of a rare hardware/firmware malfunction. | ["https://git.kernel.org/stable/c/1e8b7fb427af6b2ddd54eff66a6b428a81c96633","https://git.kernel.org/stable/c/1ec5ea9e25f582fd6999393e2f2c3bf56f234e05","https://git.kernel.org/stable/c/2429ea3b4330e3653b72b210a0d5f2a717359506","https://git.kernel.org/stable/c/46f67233b011385d53cf14d272431755de3a7c79","https://git.kernel.org/stable/c/7a7e60ed23d471a07dbbe72565d2992ee8244bbe","https://git.kernel.org/stable/c/a3e52a4c22c846858a6875e1c280030a3849e148","https://git.kernel.org/stable/c/a88a49473c94ccfd8dce1e766aacf3c627278463","https://git.kernel.org/stable/c/bf365071ea92b9579d5a272679b74052a5643e35"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46770 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: Add netif_device_attach/detach into PF reset flow Ethtool callbacks can be executed while reset is in progress and try to access deleted resources, e.g. getting coalesce settings can result in a NULL pointer dereference seen below. Reproduction steps: Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net/<interface>/device/reset when reset is in progress try to get coalesce settings using ethtool: # ethtool -c <interface> BUG: kernel NULL pointer dereference, address: 0000000000000020 PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7 RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice] RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206 RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000 R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40 FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0 Call Trace: <TASK> ice_get_coalesce+0x17/0x30 [ice] coalesce_prepare_data+0x61/0x80 ethnl_default_doit+0xde/0x340 genl_family_rcv_msg_doit+0xf2/0x150 genl_rcv_msg+0x1b3/0x2c0 netlink_rcv_skb+0x5b/0x110 genl_rcv+0x28/0x40 netlink_unicast+0x19c/0x290 netlink_sendmsg+0x222/0x490 __sys_sendto+0x1df/0x1f0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x82/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7faee60d8e27 Calling netif_device_detach() before reset makes the net core not call the driver when ethtool command is issued, the attempt to execute an ethtool command during reset will result in the following message: netlink error: No such device instead of NULL pointer dereference. Once reset is done and ice_rebuild() is executing, the netif_device_attach() is called to allow for ethtool operations to occur again in a safe manner. | ["https://git.kernel.org/stable/c/36486c9e8e01b84faaee47203eac0b7e9cc7fa4a","https://git.kernel.org/stable/c/9e3ffb839249eca113062587659224f856fe14e5","https://git.kernel.org/stable/c/d11a67634227f9f9da51938af085fb41a733848f","https://git.kernel.org/stable/c/efe8effe138044a4747d1112ebb8c454d1663723"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46848 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf/x86/intel: Limit the period on Haswell Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. | ["https://git.kernel.org/stable/c/0eaf812aa1506704f3b78be87036860e5d0fe81d","https://git.kernel.org/stable/c/15210b7c8caff4929f25d049ef8404557f8ae468","https://git.kernel.org/stable/c/25dfc9e357af8aed1ca79b318a73f2c59c1f0b2b","https://git.kernel.org/stable/c/8717dc35c0e5896f4110f4b3882f7ff787a5f73d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48841 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: fix NULL pointer dereference in ice_update_vsi_tx_ring_stats() It is possible to do NULL pointer dereference in routine that updates Tx ring stats. Currently only stats and bytes are updated when ring pointer is valid, but later on ring is accessed to propagate gathered Tx stats onto VSI stats. Change the existing logic to move to next ring when ring is NULL. | ["https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff","https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333","https://git.kernel.org/stable/c/2397270ec97c5e3009a58ac110a25e1869e9d6ff","https://git.kernel.org/stable/c/f153546913bada41a811722f2c6d17c3243a0333"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen-netfront: Fix NULL sring after live migration A NAPI is setup for each network sring to poll data to kernel The sring with source host is destroyed before live migration and new sring with target host is setup after live migration. The NAPI for the old sring is not deleted until setup new sring with target host after migration. With busy_poll/busy_read enabled, the NAPI can be polled before got deleted when resume VM. BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: xennet_poll+0xae/0xd20 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI Call Trace: finish_task_switch+0x71/0x230 timerqueue_del+0x1d/0x40 hrtimer_try_to_cancel+0xb5/0x110 xennet_alloc_rx_buffers+0x2a0/0x2a0 napi_busy_loop+0xdb/0x270 sock_poll+0x87/0x90 do_sys_poll+0x26f/0x580 tracing_map_insert+0x1d4/0x2f0 event_hist_trigger+0x14a/0x260 finish_task_switch+0x71/0x230 __schedule+0x256/0x890 recalc_sigpending+0x1b/0x50 xen_sched_clock+0x15/0x20 __rb_reserve_next+0x12d/0x140 ring_buffer_lock_reserve+0x123/0x3d0 event_triggers_call+0x87/0xb0 trace_event_buffer_commit+0x1c4/0x210 xen_clocksource_get_cycles+0x15/0x20 ktime_get_ts64+0x51/0xf0 SyS_ppoll+0x160/0x1a0 SyS_ppoll+0x160/0x1a0 do_syscall_64+0x73/0x130 entry_SYSCALL_64_after_hwframe+0x41/0xa6 ... RIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900 CR2: 0000000000000008 ---[ end trace f8601785b354351c ]--- xen frontend should remove the NAPIs for the old srings before live migration as the bond srings are destroyed There is a tiny window between the srings are set to NULL and the NAPIs are disabled, It is safe as the NAPI threads are still frozen at that time | ["https://git.kernel.org/stable/c/99859947517e446058ad7243ee81d2f9801fa3dd","https://git.kernel.org/stable/c/d50b7914fae04d840ce36491d22133070b18cca9","https://git.kernel.org/stable/c/e6860c889f4ad50b6ab696f5ea154295d72cf27a","https://git.kernel.org/stable/c/e6e897d4fe2f89c0bd94600a40bedf5e6e75e050","https://git.kernel.org/stable/c/ed773dd798bf720756d20021b8d8a4a3d7184bda","https://git.kernel.org/stable/c/f2dd60fd3fe98bd36a91b0c6e10bfe9d66258f84"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36476 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs: Ensure 'ib_sge list' is accessible Move the declaration of the 'ib_sge list' variable outside the 'always_invalidate' block to ensure it remains accessible for use throughout the function. Previously, 'ib_sge list' was declared within the 'always_invalidate' block, limiting its accessibility, then caused a 'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10 This change ensures the variable is available for subsequent operations that require it. [1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/ | ["https://git.kernel.org/stable/c/143378075904e78b3b2a810099bcc3b3d82d762f","https://git.kernel.org/stable/c/32e1e748a85bd52b20b3857d80fd166d22fa455a","https://git.kernel.org/stable/c/6ffb5c1885195ae5211a12b4acd2d51843ca41b0","https://git.kernel.org/stable/c/7eaa71f56a6f7ab87957213472dc6d4055862722","https://git.kernel.org/stable/c/b238f61cc394d5fef27b26d7d9aa383ebfddabb0","https://git.kernel.org/stable/c/fb514b31395946022f13a08e06a435f53cf9e8b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-55916 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: util: Avoid accessing a ringbuffer not initialized yet If the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is fully initialized, we can hit the panic below: hv_utils: Registering HyperV Utility Driver hv_vmbus: registering driver hv_utils ... BUG: kernel NULL pointer dereference, address: 0000000000000000 CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1 RIP: 0010:hv_pkt_iter_first+0x12/0xd0 Call Trace: ... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 </IRQ> <TASK> asm_sysvec_hyperv_stimer0 ... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_read This can happen because the KVP/VSS channel callback can be invoked even before the channel is fully opened: 1) as soon as hv_kvp_init() -> hvutil_transport_init() creates /dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and register itself to the driver by writing a message KVP_OP_REGISTER1 to the file (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and reading the file for the driver's response, which is handled by hvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done(). 2) the problem with kvp_register_done() is that it can cause the channel callback to be called even before the channel is fully opened, and when the channel callback is starting to run, util_probe()-> vmbus_open() may have not initialized the ringbuffer yet, so the callback can hit the panic of NULL pointer dereference. To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in __vmbus_open(), just before the first hv_ringbuffer_init(), and then we unload and reload the driver hv_utils, and run the daemon manually within the 10 seconds. Fix the panic by reordering the steps in util_probe() so the char dev entry used by the KVP or VSS daemon is not created until after vmbus_open() has completed. This reordering prevents the race condition from happening. | ["https://git.kernel.org/stable/c/042253c57be901bfd19f15b68267442b70f510d5","https://git.kernel.org/stable/c/07a756a49f4b4290b49ea46e089cbe6f79ff8d26","https://git.kernel.org/stable/c/3dd7a30c6d7f90afcf19e9b072f572ba524d7ec6","https://git.kernel.org/stable/c/718fe694a334be9d1a89eed22602369ac18d6583","https://git.kernel.org/stable/c/89fcec5e466b3ac9b376e0d621c71effa1a7983f","https://git.kernel.org/stable/c/d81f4e73aff9b861671df60e5100ad25cc16fbf8","https://git.kernel.org/stable/c/f091a224a2c82f1e302b1768d73bb6332f687321"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56763 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Prevent bad count for tracing_cpumask_write If a large count is provided, it will trigger a warning in bitmap_parse_user. Also check zero for it. | ["https://git.kernel.org/stable/c/03041e474a6a8f1bfd4b96b164bb3165c48fa1a3","https://git.kernel.org/stable/c/1cca920af19df5dd91254e5ff35e68e911683706","https://git.kernel.org/stable/c/2558d753df0628d4187d8e1fd989339460f4f364","https://git.kernel.org/stable/c/3d15f4c2449558ffe83b4dba30614ef1cd6937c3","https://git.kernel.org/stable/c/98feccbf32cfdde8c722bc4587aaa60ee5ac33f0","https://git.kernel.org/stable/c/f60172b447317cb6c5e74b5601a151866269baf6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56767 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: at_xdmac: avoid null_prt_deref in at_xdmac_prep_dma_memset The at_xdmac_memset_create_desc may return NULL, which will lead to a null pointer dereference. For example, the len input is error, or the atchan->free_descs_list is empty and memory is exhausted. Therefore, add check to avoid this. | ["https://git.kernel.org/stable/c/3d229600c54e9e0909080ecaf1aab0642aefa5f0","https://git.kernel.org/stable/c/54376d8d26596f98ed7432a788314bb9154bf3e3","https://git.kernel.org/stable/c/8d364597de9ce2a5f52714224bfe6c2e7a29b303","https://git.kernel.org/stable/c/c43ec96e8d34399bd9dab2f2dc316b904892133f","https://git.kernel.org/stable/c/e658f1c133b854b2ae799147301d82dddb8f3162","https://git.kernel.org/stable/c/ed1a8aaa344522c0c349ac9042db27ad130ef913","https://git.kernel.org/stable/c/fdba6d5e455388377ec7e82a5913ddfcc7edd93b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56769 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg Syzbot reports [1] an uninitialized value issue found by KMSAN in dib3000_read_reg(). Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case that call fails, the buffer may end up with some undefined values. Since no elaborate error handling is expected in dib3000_write_reg(), simply zero out rb buffer to mitigate the problem. [1] Syzkaller report dvb-usb: bulk message failed: -22 (6/0) ===================================================== BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110 ... Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 ... | ["https://git.kernel.org/stable/c/035772fcd631eee2756b31cb6df249c0a8d453d7","https://git.kernel.org/stable/c/1d6de21f00293d819b5ca6dbe75ff1f3b6392140","https://git.kernel.org/stable/c/2dd59fe0e19e1ab955259978082b62e5751924c7","https://git.kernel.org/stable/c/3876e3a1c31a58a352c6bf5d2a90e3304445a637","https://git.kernel.org/stable/c/53106510736e734ce8b731ba871363389bfbf4c9","https://git.kernel.org/stable/c/c1197c1457bb7098cf46366e898eb52b41b6876a","https://git.kernel.org/stable/c/e11778189513cd7fb2edced5bd053bc18ede8418"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56779 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur The action force umount(umount -f) will attempt to kill all rpc_task even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpc_task to nfs server. NFS CLIENT thread1 thread2 open("file") ... nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_task While processing an open request, nfsd will first attempt to find or allocate an nfs4_openowner. If it finds an nfs4_openowner that is not marked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since two rpc_task can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered. NFS SERVER nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive ======================================================================= BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on __kmem_cache_shutdown() ----------------------------------------------------------------------- Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated--- | ["https://git.kernel.org/stable/c/0ab0a3ad24e970e894abcac58f85c332d1726749","https://git.kernel.org/stable/c/2d505a801e57428057563762f67a5a62009b2600","https://git.kernel.org/stable/c/37dfc81266d3a32294524bfadd3396614f8633ee","https://git.kernel.org/stable/c/45abb68c941ebc9a35c6d3a7b08196712093c636","https://git.kernel.org/stable/c/6f73f920b7ad0084373e46121d7ac34117aed652","https://git.kernel.org/stable/c/98100e88dd8865999dc6379a3356cd799795fe7b","https://git.kernel.org/stable/c/a85364f0d30dee01c5d5b4afa55a9629a8f36d8e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56781 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/prom_init: Fixup missing powermac #size-cells On some powermacs `escc` nodes are missing `#size-cells` properties, which is deprecated and now triggers a warning at boot since commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"). For example: Missing '#size-cells' in /pci@f2000000/mac-io@c/escc@13000 WARNING: CPU: 0 PID: 0 at drivers/of/base.c:133 of_bus_n_size_cells+0x98/0x108 Hardware name: PowerMac3,1 7400 0xc0209 PowerMac ... Call Trace: of_bus_n_size_cells+0x98/0x108 (unreliable) of_bus_default_count_cells+0x40/0x60 __of_get_address+0xc8/0x21c __of_address_to_resource+0x5c/0x228 pmz_init_port+0x5c/0x2ec pmz_probe.isra.0+0x144/0x1e4 pmz_console_init+0x10/0x48 console_init+0xcc/0x138 start_kernel+0x5c4/0x694 As powermacs boot via prom_init it's possible to add the missing properties to the device tree during boot, avoiding the warning. Note that `escc-legacy` nodes are also missing `#size-cells` properties, but they are skipped by the macio driver, so leave them alone. Depends-on: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling") | ["https://git.kernel.org/stable/c/0b94d838018fb0a824e0cd3149034928c99fb1b7","https://git.kernel.org/stable/c/296a109fa77110ba5267fe0e90a26005eecc2726","https://git.kernel.org/stable/c/691284c2cd33ffaa0b35ce53b3286b90621e9dc9","https://git.kernel.org/stable/c/6d5f0453a2228607333bff0c85238a3cb495d194","https://git.kernel.org/stable/c/a79a7e3c03ae2a07f68b5f24d5ed549f9799ec89","https://git.kernel.org/stable/c/cf89c9434af122f28a3552e6f9cc5158c33ce50a","https://git.kernel.org/stable/c/ee68554d2c03e32077f7b984e5289fdb005036d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56785 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: MIPS: Loongson64: DTS: Really fix PCIe port nodes for ls7a Fix the dtc warnings: arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/ls7a-pch.dtsi:68.16-416.5: Warning (interrupt_provider): /bus@10000000/pci@1a000000: '#interrupt-cells' found, but node is not an interrupt provider arch/mips/boot/dts/loongson/loongson64g_4core_ls7a.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider' And a runtime warning introduced in commit 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells handling"): WARNING: CPU: 0 PID: 1 at drivers/of/base.c:106 of_bus_n_addr_cells+0x9c/0xe0 Missing '#address-cells' in /bus@10000000/pci@1a000000/pci_bridge@9,0 The fix is similar to commit d89a415ff8d5 ("MIPS: Loongson64: DTS: Fix PCIe port nodes for ls7a"), which has fixed the issue for ls2k (despite its subject mentions ls7a). | ["https://git.kernel.org/stable/c/01575f2ff8ba578a3436f230668bd056dc2eb823","https://git.kernel.org/stable/c/4fbd66d8254cedfd1218393f39d83b6c07a01917","https://git.kernel.org/stable/c/5a2eaa3ad2b803c7ea442c6db7379466ee73c024","https://git.kernel.org/stable/c/8ef9ea1503d0a129cc6f5cf48fb63633efa5d766","https://git.kernel.org/stable/c/a7fd78075031871bc68fc56fdaa6e7a3934064b1","https://git.kernel.org/stable/c/c8ee41fc3522c6659e324d90bc2ccd3b6310d7fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57802 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netrom: check buffer length before accessing it Syzkaller reports an uninit value read from ax25cmp when sending raw message through ieee802154 implementation. ===================================================== BUG: KMSAN: uninit-value in ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 ax25cmp+0x3a5/0x460 net/ax25/ax25_addr.c:119 nr_dev_get+0x20e/0x450 net/netrom/nr_route.c:601 nr_route_frame+0x1a2/0xfc0 net/netrom/nr_route.c:774 nr_xmit+0x5a/0x1c0 net/netrom/nr_dev.c:144 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] raw_sendmsg+0x654/0xc10 net/ieee802154/socket.c:299 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2780 sock_alloc_send_skb include/net/sock.h:1884 [inline] raw_sendmsg+0x36d/0xc10 net/ieee802154/socket.c:282 ieee802154_sock_sendmsg+0x91/0xc0 net/ieee802154/socket.c:96 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5037 Comm: syz-executor166 Not tainted 6.7.0-rc7-syzkaller-00003-gfbafc3e621c3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== This issue occurs because the skb buffer is too small, and it's actual allocation is aligned. This hides an actual issue, which is that nr_route_frame does not validate the buffer size before using it. Fix this issue by checking skb->len before accessing any fields in skb->data. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/3ba7f80d98d4965349cfcd258dd78418496c1625","https://git.kernel.org/stable/c/64e9f54a14f2887be8634fb85cd2f13bec18a184","https://git.kernel.org/stable/c/769e36c2119a51070faf58819c58274f57a088db","https://git.kernel.org/stable/c/78a110332ae268d0b005247c3b9a7d703b875c49","https://git.kernel.org/stable/c/a4fd163aed2edd967a244499754dec991d8b4c7d","https://git.kernel.org/stable/c/cf6befa7c569787f53440274bbed1405fc07738d","https://git.kernel.org/stable/c/f647d72245aadce30618f4c8fd3803904418dbec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57890 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Prevent integer overflow issue In the expression "cmd.wqe_size * cmd.wr_count", both variables are u32 values that come from the user so the multiplication can lead to integer wrapping. Then we pass the result to uverbs_request_next_ptr() which also could potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)" multiplication can also overflow on 32bit systems although it's fine on 64bit systems. This patch does two things. First, I've re-arranged the condition in uverbs_request_next_ptr() so that the use controlled variable "len" is on one side of the comparison by itself without any math. Then I've modified all the callers to use size_mul() for the multiplications. | ["https://git.kernel.org/stable/c/346db03e9926ab7117ed9bf19665699c037c773c","https://git.kernel.org/stable/c/42a6eb4ed7a9a41ba0b83eb0c7e0225b5fca5608","https://git.kernel.org/stable/c/b3ef4ae713360501182695dd47d6b4f6e1a43eb8","https://git.kernel.org/stable/c/b92667f755749cf10d9ef1088865c555ae83ffb7","https://git.kernel.org/stable/c/c2f961c46ea0e5274c5c320d007c2dd949cf627a","https://git.kernel.org/stable/c/c57721b24bd897338a81a0ca5fff41600f0f1ad1","https://git.kernel.org/stable/c/d0257e089d1bbd35c69b6c97ff73e3690ab149a9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27011 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak in map from abort path The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping. Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator. [ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967] <TASK> [ 6170.287973] ? __warn+0x9f/0x1a0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092] ? report_bug+0x1b1/0x1e0 [ 6170.288104] ? handle_bug+0x3c/0x70 [ 6170.288112] ? exc_invalid_op+0x17/0x40 [ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20 [ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables] | ["https://git.kernel.org/stable/c/49d0e656d19dfb2d4d7c230e4a720d37b3decff6","https://git.kernel.org/stable/c/86a1471d7cde792941109b93b558b5dc078b9ee9","https://git.kernel.org/stable/c/a1bd2a38a1c6388fc8556816dc203c3e9dc52237","https://git.kernel.org/stable/c/49d0e656d19dfb2d4d7c230e4a720d37b3decff6","https://git.kernel.org/stable/c/86a1471d7cde792941109b93b558b5dc078b9ee9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-33655 | Medium | fixed |
|
When sending malicous data to kernel by ioctl cmd FBIOPUT_VSCREENINFO,kernel will write memory out of bounds. | ["http://www.openwall.com/lists/oss-security/2022/07/19/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","http://www.openwall.com/lists/oss-security/2022/07/19/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=086ff84617185393a0bbf25830c4f36412a7d3f4","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47723 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds. | ["https://git.kernel.org/stable/c/0338e66cba272351ca9d7d03f3628e390e70963b","https://git.kernel.org/stable/c/128d5cfdcf844cb690c9295a3a1c1114c21fc15a","https://git.kernel.org/stable/c/5ad6284c8d433f8a213111c5c44ead4d9705b622","https://git.kernel.org/stable/c/6ce8b6ab44a8b5918c0ee373d4ad19d19017931b","https://git.kernel.org/stable/c/96855f40e152989c9e7c20c4691ace5581098acc","https://git.kernel.org/stable/c/c1ba4b8ca799ff1d99d01f37d7ccb7d5ba5533d2","https://git.kernel.org/stable/c/d1017d2a0f3f16dc1db5120e7ddbe7c6680425b0","https://git.kernel.org/stable/c/e63866a475562810500ea7f784099bfe341e761a","https://git.kernel.org/stable/c/ead82533278502428883085a787d5a00f15e5eb9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49900 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get(). | ["https://git.kernel.org/stable/c/2b59ffad47db1c46af25ccad157bb3b25147c35c","https://git.kernel.org/stable/c/6041536d18c5f51a84bc37cd568cbab61870031e","https://git.kernel.org/stable/c/7b24d41d47a6805c45378debf8bd115675d41da8","https://git.kernel.org/stable/c/7c244d5b48284a770d96ff703df2dfeadf804a73","https://git.kernel.org/stable/c/8ad8b531de79c348bcb8133e7f5e827b884226af","https://git.kernel.org/stable/c/8b1dcf25c26d42e4a68c4725ce52a0543c7878cc","https://git.kernel.org/stable/c/c076b3746224982eebdba5c9e4b1467e146c0d64","https://git.kernel.org/stable/c/d7444f91a9f93eaa48827087ed0f3381c194181d","https://git.kernel.org/stable/c/dac398ed272a378d2f42ac68ae408333a51baf52"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48967 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFC: nci: Bounds check struct nfc_target arrays While running under CONFIG_FORTIFY_SOURCE=y, syzkaller reported: memcpy: detected field-spanning write (size 129) of single field "target->sensf_res" at net/nfc/nci/ntf.c:260 (size 18) This appears to be a legitimate lack of bounds checking in nci_add_new_protocol(). Add the missing checks. | ["https://git.kernel.org/stable/c/27eb2d7a1b9987b6d0429b7716b1ff3b82c4ffc9","https://git.kernel.org/stable/c/6778434706940b8fad7ef35f410d2b9929f256d2","https://git.kernel.org/stable/c/6b37f0dc0638d13a006f2f24d2f6ca61e83bc714","https://git.kernel.org/stable/c/908b2da426fe9c3ce74cf541ba40e7a4251db191","https://git.kernel.org/stable/c/cff35329070b96b4484d23f9f48a5ca2c947e750","https://git.kernel.org/stable/c/dbdcfb9f6748218a149f62468d6297ce3f014e9c","https://git.kernel.org/stable/c/e329e71013c9b5a4535b099208493c7826ee4a64","https://git.kernel.org/stable/c/f41547546db9af99da2c34e3368664d7a79cefae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58007 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. | ["https://git.kernel.org/stable/c/0a92feddae0634a0b87c04b19d343f6af97af700","https://git.kernel.org/stable/c/22cf4fae6660b6e1a583a41cbf84e3046ca9ccd0","https://git.kernel.org/stable/c/2495c6598731b6d7f565140f2bd63ef4bc36ce7d","https://git.kernel.org/stable/c/2d09d3c9afa2fc422ac3df7c9b8534f350ee19dd","https://git.kernel.org/stable/c/407c928305c1a37232a63811c400ef616f85ccbc","https://git.kernel.org/stable/c/47470acd719d45c4c8c418c07962f74cc995652b","https://git.kernel.org/stable/c/7445fa05317534bbd8b373c0eff8319187916030","https://git.kernel.org/stable/c/9c88b3a3fae4d60641c3a45be66269d00eff33cd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21782 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: orangefs: fix a oob in orangefs_debug_write I got a syzbot report: slab-out-of-bounds Read in orangefs_debug_write... several people suggested fixes, I tested Al Viro's suggestion and made this patch. | ["https://git.kernel.org/stable/c/09d472a18c0ee1d5b83612cb919e33a1610fea16","https://git.kernel.org/stable/c/18b7f841109f697840fe8633cf7ed7d32bd3f91b","https://git.kernel.org/stable/c/1c5244299241cf49d8ae7b5054e299cc8faa4e09","https://git.kernel.org/stable/c/1da2697307dad281dd690a19441b5ca4af92d786","https://git.kernel.org/stable/c/2b84a231910cef2e0a16d29294afabfb69112087","https://git.kernel.org/stable/c/8725882b0f691f8113b230aea9df0256030a63a6","https://git.kernel.org/stable/c/897f496b946fdcfab5983c983e4b513ab6682364","https://git.kernel.org/stable/c/f7c848431632598ff9bce57a659db6af60d75b39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48650 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in __qlt_24xx_handle_abts() Commit 8f394da36a36 ("scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG") made the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command, but it missed to clean up the allocated memory for the management command. | ["https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf","https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7","https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82","https://git.kernel.org/stable/c/601be20fc6a1b762044d2398befffd6bf236cebf","https://git.kernel.org/stable/c/6a4236ed47f5b0a57eb6b8fb1c351b15b3d341d7","https://git.kernel.org/stable/c/89df49e561b4a8948521fc3f8a013012eaa08f82"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52481 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled). | ["https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25","https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513","https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c","https://git.kernel.org/stable/c/32b0a4ffcaea44a00a61e40c0d1bcc50362aee25","https://git.kernel.org/stable/c/471470bc7052d28ce125901877dd10e4c048e513","https://git.kernel.org/stable/c/6e3ae2927b432a3b7c8374f14dbc1bd9ebe4372c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27030 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-af: Use separate handlers for interrupts For PF to AF interrupt vector and VF to AF vector same interrupt handler is registered which is causing race condition. When two interrupts are raised to two CPUs at same time then two cores serve same event corrupting the data. | ["https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44","https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701","https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c","https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a","https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70","https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2","https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c","https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d","https://git.kernel.org/stable/c/29d2550d79a8cbd31e0fbaa5c0e2a2efdc444e44","https://git.kernel.org/stable/c/4fedae8f9eafa2ac8cdaca58e315f52a7e2a8701","https://git.kernel.org/stable/c/50e60de381c342008c0956fd762e1c26408f372c","https://git.kernel.org/stable/c/766c2627acb2d9d1722cce2e24837044d52d888a","https://git.kernel.org/stable/c/772f18ded0e240cc1fa2b7020cc640e3e5c32b70","https://git.kernel.org/stable/c/94cb17e5cf3a3c484063abc0ce4b8a2b2e8c1cb2","https://git.kernel.org/stable/c/ad6759e233db6fcc131055f8e23b4eafbe81053c","https://git.kernel.org/stable/c/dc29dd00705a62c77de75b6d752259b869aac49d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50234 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated--- | ["https://git.kernel.org/stable/c/07c90acb071b9954e1fecb1e4f4f13d12c544b34","https://git.kernel.org/stable/c/23f9cef17ee315777dbe88d5c11ff6166e4d0699","https://git.kernel.org/stable/c/271d282ecc15d7012e71ca82c89a6c0e13a063dd","https://git.kernel.org/stable/c/8ac22fe1e2b104c37e4fecd97735f64bd6349ebc","https://git.kernel.org/stable/c/8af8294d369a871cdbcdbb4d13b87d2d6e490a1f","https://git.kernel.org/stable/c/9d89941e51259c2b0b8e9c10c6f1f74200d7444f","https://git.kernel.org/stable/c/cedf0f1db8d5f3524339c2c6e35a8505b0f1ab73","https://git.kernel.org/stable/c/d0231f43df473e2f80372d0ca150eb3619932ef9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49903 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition. | ["https://git.kernel.org/stable/c/0c238da83f56bb895cab1e5851d034ac45b158d1","https://git.kernel.org/stable/c/3126ccde51f51b0648c8cdccaf916e8bd062e972","https://git.kernel.org/stable/c/4218b31ecc7af7e191768d32e32ed4386d8f9b76","https://git.kernel.org/stable/c/4ac58f7734937f3249da734ede946dfb3b1af5e4","https://git.kernel.org/stable/c/95accb7183badca387f7a8d19a2475cf3089f148","https://git.kernel.org/stable/c/a9603a6f75df2fd8125cd208c98cfaa0fe3f7505","https://git.kernel.org/stable/c/d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234","https://git.kernel.org/stable/c/e7ae14f7ee76c6ef5a48aebab1a278ad78f42619","https://git.kernel.org/stable/c/fd026b6b6758d5569705c02540b40f3bbf822b9a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49981 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. | ["https://git.kernel.org/stable/c/10941d4f99a5a34999121b314afcd9c0a1c14f15","https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621","https://git.kernel.org/stable/c/5098b9e6377577fe13d03e1d8914930f014a3314","https://git.kernel.org/stable/c/60b6968341a6dd5353554f3e72db554693a128a5","https://git.kernel.org/stable/c/63bbe26471ebdcc3c20bb4cc3950d666279ad658","https://git.kernel.org/stable/c/b0686aedc5f1343442d044bd64eeac7e7a391f4e","https://git.kernel.org/stable/c/bf6be32e2d39f6301ff1831e249d32a8744ab28a","https://git.kernel.org/stable/c/c5a85ed88e043474161bbfe54002c89c1cb50ee2","https://git.kernel.org/stable/c/d925e9f7fb5a2dbefd1a73fc01061f38c7becd4c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41849 | Medium | N/A | drivers/video/fbdev/smscufx.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a USB device while calling open(), aka a race condition between ufx_ops_open and ufx_usb_disconnect. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5610bcfe8693c02e2e4c8b31427f1bdbdecc839c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220925133243.GA383897%40ubuntu/T/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48646 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sfc/siena: fix null pointer dereference in efx_hard_start_xmit Like in previous patch for sfc, prevent potential (but unlikely) NULL pointer dereference. | ["https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa","https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a","https://git.kernel.org/stable/c/589c6eded10c77a12b7b2cf235b6b19a2bdb91fa","https://git.kernel.org/stable/c/a4eadca702dff0768dd01be6789bbec2a18e5b0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35982 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid infinite loop trying to resize local TT If the MTU of one of an attached interface becomes too small to transmit the local translation table then it must be resized to fit inside all fragments (when enabled) or a single packet. But if the MTU becomes too low to transmit even the header + the VLAN specific part then the resizing of the local TT will never succeed. This can for example happen when the usable space is 110 bytes and 11 VLANs are on top of batman-adv. In this case, at least 116 byte would be needed. There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) in the log but the function will never finish. Problem here is that the timeout will be halved all the time and will then stagnate at 0 and therefore never be able to reduce the table even more. There are other scenarios possible with a similar result. The number of BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too high to fit inside a packet. Such a scenario can therefore happen also with only a single VLAN + 7 non-purgable addresses - requiring at least 120 bytes. While this should be handled proactively when: * interface with too low MTU is added * VLAN is added * non-purgeable local mac is added * MTU of an attached interface is reduced * fragmentation setting gets disabled (which most likely requires dropping attached interfaces) not all of these scenarios can be prevented because batman-adv is only consuming events without the the possibility to prevent these actions (non-purgable MAC address added, MTU of an attached interface is reduced). It is therefore necessary to also make sure that the code is able to handle also the situations when there were already incompatible system configuration are present. | ["https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924","https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259","https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2","https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d","https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f","https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa","https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6","https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0","https://git.kernel.org/stable/c/04720ea2e6c64459a90ca28570ea78335eccd924","https://git.kernel.org/stable/c/3fe79b2c83461edbbf86ed8a6f3924820ff89259","https://git.kernel.org/stable/c/4ca2a5fb54ea2cc43edea614207fcede562d91c2","https://git.kernel.org/stable/c/70a8be9dc2fb65d67f8c1e0c88c587e08e2e575d","https://git.kernel.org/stable/c/87b6af1a7683e021710c08fc0551fc078346032f","https://git.kernel.org/stable/c/b1f532a3b1e6d2e5559c7ace49322922637a28aa","https://git.kernel.org/stable/c/b3ddf6904073990492454b1dd1c10a24be8c74c6","https://git.kernel.org/stable/c/ca54e2671548616ad34885f90d4f26f7adb088f0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56774 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: add a sanity check for btrfs root in btrfs_search_slot() Syzbot reports a null-ptr-deref in btrfs_search_slot(). The reproducer is using rescue=ibadroots, and the extent tree root is corrupted thus the extent tree is NULL. When scrub tries to search the extent tree to gather the needed extent info, btrfs_search_slot() doesn't check if the target root is NULL or not, resulting the null-ptr-deref. Add sanity check for btrfs root before using it in btrfs_search_slot(). | ["https://git.kernel.org/stable/c/3ed51857a50f530ac7a1482e069dfbd1298558d4","https://git.kernel.org/stable/c/757171d1369b3b47f36932d40a05a0715496dcab","https://git.kernel.org/stable/c/93992c3d9629b02dccf6849238559d5c24f2dece","https://git.kernel.org/stable/c/c71d114ef68c95da5a82ec85a721ab31f5bd905b","https://git.kernel.org/stable/c/db66fb87c21e8ae724886e6a464dcbac562a64c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56776 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/sti: avoid potential dereference of error pointers The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. | ["https://git.kernel.org/stable/c/40725c5fabee804fecce41d4d5c5bae80c45e1c4","https://git.kernel.org/stable/c/831214f77037de02afc287eae93ce97f218d8c04","https://git.kernel.org/stable/c/8ab73ac97c0fa528f66eeccd9bb53eb6eb7d20dc","https://git.kernel.org/stable/c/e98ff67f5a68114804607de549c2350d27628fc7","https://git.kernel.org/stable/c/f67786293193cf01ebcc6fdbcbd1587b24f52679"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56777 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_check The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. | ["https://git.kernel.org/stable/c/3cf2e7c448e246f7e700c7aa47450d1e27579559","https://git.kernel.org/stable/c/997b64c3f4c1827c5cfda8ae7f5d13f78d28b541","https://git.kernel.org/stable/c/b79612ed6bc1a184c45427105c851b5b2d4342ca","https://git.kernel.org/stable/c/e965e771b069421c233d674c3c8cd8c7f7245f42","https://git.kernel.org/stable/c/f5804567cf9605d6e5ec46c0bb786f7d50f18c13"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56778 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_check The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. | ["https://git.kernel.org/stable/c/31c857e7496d34e5a32a6f75bc024d0b06fd646a","https://git.kernel.org/stable/c/6b0d0d6e9d3c26697230bf7dc9e6b52bdb24086f","https://git.kernel.org/stable/c/82a5312f874fb18f045d9658e9bd290e3b0621c0","https://git.kernel.org/stable/c/837eb99ad3340c7a9febf454f41c8e3edb68ac1e","https://git.kernel.org/stable/c/c1ab40a1fdfee732c7e6ff2fb8253760293e47e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56787 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: imx8m: Probe the SoC driver as platform driver With driver_async_probe=* on kernel command line, the following trace is produced because on i.MX8M Plus hardware because the soc-imx8m.c driver calls of_clk_get_by_name() which returns -EPROBE_DEFER because the clock driver is not yet probed. This was not detected during regular testing without driver_async_probe. Convert the SoC code to platform driver and instantiate a platform device in its current device_initcall() to probe the platform driver. Rework .soc_revision callback to always return valid error code and return SoC revision via parameter. This way, if anything in the .soc_revision callback return -EPROBE_DEFER, it gets propagated to .probe and the .probe will get retried later. " ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180 CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603 Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT) pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : imx8mm_soc_revision+0xdc/0x180 lr : imx8mm_soc_revision+0xd0/0x180 sp : ffff8000821fbcc0 x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120 x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311 x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfb x20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffff x17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8 x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801 x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95c x8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3 x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfb Call trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- SoC: i.MX8MP revision 1.1 " | ["https://git.kernel.org/stable/c/2129f6faa5dfe8c6b87aad11720bf75edd77d3e4","https://git.kernel.org/stable/c/997a3c04d7fa3d1d385c14691350d096fada648c","https://git.kernel.org/stable/c/9cc832d37799dbea950c4c8a34721b02b8b5a8ff","https://git.kernel.org/stable/c/e497edb8f31ec2c2b6f4ce930e175aa2da8be334","https://git.kernel.org/stable/c/ea2ff66feb5f9b183f9e2f9d06c21340bd88de12"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57895 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: set ATTR_CTIME flags when setting mtime David reported that the new warning from setattr_copy_mgtime is coming like the following. [ 113.215316] ------------[ cut here ]------------ [ 113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattr_copy+0x1ee/0x200 [ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234 [ 113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [ 113.221530] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] [ 113.222220] RIP: 0010:setattr_copy+0x1ee/0x200 [ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0 [ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202 [ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003 [ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0 [ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa [ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38 [ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000 [ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000 [ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0 [ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 113.234797] Call Trace: [ 113.235116] <TASK> [ 113.235393] ? __warn+0x73/0xd0 [ 113.235802] ? setattr_copy+0x1ee/0x200 [ 113.236299] ? report_bug+0xf3/0x1e0 [ 113.236757] ? handle_bug+0x4d/0x90 [ 113.237202] ? exc_invalid_op+0x13/0x60 [ 113.237689] ? asm_exc_invalid_op+0x16/0x20 [ 113.238185] ? setattr_copy+0x1ee/0x200 [ 113.238692] btrfs_setattr+0x80/0x820 [btrfs] [ 113.239285] ? get_stack_info_noinstr+0x12/0xf0 [ 113.239857] ? __module_address+0x22/0xa0 [ 113.240368] ? handle_ksmbd_work+0x6e/0x460 [ksmbd] [ 113.240993] ? __module_text_address+0x9/0x50 [ 113.241545] ? __module_address+0x22/0xa0 [ 113.242033] ? unwind_next_frame+0x10e/0x920 [ 113.242600] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 113.243268] notify_change+0x2c2/0x4e0 [ 113.243746] ? stack_depot_save_flags+0x27/0x730 [ 113.244339] ? set_file_basic_info+0x130/0x2b0 [ksmbd] [ 113.244993] set_file_basic_info+0x130/0x2b0 [ksmbd] [ 113.245613] ? process_scheduled_works+0xbe/0x310 [ 113.246181] ? worker_thread+0x100/0x240 [ 113.246696] ? kthread+0xc8/0x100 [ 113.247126] ? ret_from_fork+0x2b/0x40 [ 113.247606] ? ret_from_fork_asm+0x1a/0x30 [ 113.248132] smb2_set_info+0x63f/0xa70 [ksmbd] ksmbd is trying to set the atime and mtime via notify_change without also setting the ctime. so This patch add ATTR_CTIME flags when setting mtime to avoid a warning. | ["https://git.kernel.org/stable/c/1d7ee876b8b96efc14e177a7fe8d45ac25d68849","https://git.kernel.org/stable/c/21e46a79bbe6c4e1aa73b3ed998130f2ff07b128","https://git.kernel.org/stable/c/52cefcff6a4a814f4f8e357422fcfb71fd2ebf75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50138 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error. | ["https://git.kernel.org/stable/c/5eb34999d118e69a20dc0c6556f315fcb0a1f8d3","https://git.kernel.org/stable/c/8b62645b09f870d70c7910e7550289d444239a46","https://git.kernel.org/stable/c/ca30e682e5d6de44d12c4610767811c9a21d59ba","https://git.kernel.org/stable/c/f9543375d9b150b2bcf16bb182e6b62309db0888"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36023 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Julia Lawall reported this null pointer dereference, this should fix it. | ["https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a","https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e","https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac","https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1","https://git.kernel.org/stable/c/214a6c4a28c11d67044e6cf3a0ab415050d9f03a","https://git.kernel.org/stable/c/2e2177f94c0e0bc41323d7b6975a5f4820ed347e","https://git.kernel.org/stable/c/9bf93dcfc453fae192fe5d7874b89699e8f800ac","https://git.kernel.org/stable/c/b972e8ac3f44f693127a2806031962d100dfc4d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41066 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Add tx check to prevent skb leak Below is a summary of how the driver stores a reference to an skb during transmit: tx_buff[free_map[consumer_index]]->skb = new_skb; free_map[consumer_index] = IBMVNIC_INVALID_MAP; consumer_index ++; Where variable data looks like this: free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3] consumer_index^ tx_buff == [skb=null, skb=<ptr>, skb=<ptr>, skb=null, skb=null] The driver has checks to ensure that free_map[consumer_index] pointed to a valid index but there was no check to ensure that this index pointed to an unused/null skb address. So, if, by some chance, our free_map and tx_buff lists become out of sync then we were previously risking an skb memory leak. This could then cause tcp congestion control to stop sending packets, eventually leading to ETIMEDOUT. Therefore, add a conditional to ensure that the skb address is null. If not then warn the user (because this is still a bug that should be patched) and free the old pointer to prevent memleak/tcp problems. | ["https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561","https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c","https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06","https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a","https://git.kernel.org/stable/c/0983d288caf984de0202c66641577b739caad561","https://git.kernel.org/stable/c/16ad1557cae582e79bb82dddd612d9bdfaa11d4c","https://git.kernel.org/stable/c/267c61c4afed0ff9a2e83462abad3f41d8ca1f06","https://git.kernel.org/stable/c/e7b75def33eae61ddaad6cb616c517dc3882eb2a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41076 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix memory leak in nfs4_set_security_label We leak nfs_fattr and nfs4_label every time we set a security xattr. | ["https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c","https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68","https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e","https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c","https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c","https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68","https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e","https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42067 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error. | ["https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a","https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5","https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a","https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7","https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730","https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46726 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Ensure index calculation will not overflow [WHY & HOW] Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will never overflow and exceess array size. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. | ["https://git.kernel.org/stable/c/3dc6bb57dab36b38b7374af0ac916174c146b6ed","https://git.kernel.org/stable/c/733ae185502d30bbe79575167b6178cfb6c5d6bd","https://git.kernel.org/stable/c/8e2734bf444767fed787305ccdcb36a2be5301a2","https://git.kernel.org/stable/c/d705b5869f6b1b46ad5ceb1bd2a08c04f7e5003b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50188 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed. | ["https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4","https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a","https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5","https://git.kernel.org/stable/c/ad0d76b8ee5db063791cc2e7a30ffc9852ac37c4","https://git.kernel.org/stable/c/c1944b4253649fc6f2fb53e7d6302eb414d2182c","https://git.kernel.org/stable/c/e3f2de32dae35bc7d173377dc97b5bc9fcd9fc84"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52913 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix potential context UAFs gem_context_register() makes the context visible to userspace, and which point a separate thread can trigger the I915_GEM_CONTEXT_DESTROY ioctl. So we need to ensure that nothing uses the ctx ptr after this. And we need to ensure that adding the ctx to the xarray is the *last* thing that gem_context_register() does with the ctx pointer. [tursulin: Stable and fixes tags add/tidy.] (cherry picked from commit bed4b455cf5374e68879be56971c1da563bcd90c) | ["https://git.kernel.org/stable/c/ae278887193110dfeb857ea63e243a3851fbb0bc","https://git.kernel.org/stable/c/afce71ff6daa9c0f852df0727fe32c6fb107f0fa","https://git.kernel.org/stable/c/b696c627b3f56e173f7f70b8487d66da8ff22506"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50243 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback. | ["https://git.kernel.org/stable/c/509c1c6b499a4d9026b58c6e1c3a10ed8db1839f","https://git.kernel.org/stable/c/68b39c0765de7c97b34889c1f5e81c2a223fdacc","https://git.kernel.org/stable/c/8e87c9aa8cf92cfceaff0aab244318bbb8b35137","https://git.kernel.org/stable/c/a33fb016e49e37aafab18dc3c8314d6399cb4727"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48839 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/packet: fix slab-out-of-bounds access in packet_recvmsg() syzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH and mmap operations, tpacket_rcv() is queueing skbs with garbage in skb->cb[], triggering a too big copy [1] Presumably, users of af_packet using mmap() already gets correct metadata from the mapped buffer, we can simply make sure to clear 12 bytes that might be copied to user space later. BUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline] BUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 Write of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631 CPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 memcpy+0x39/0x60 mm/kasan/shadow.c:66 memcpy include/linux/fortify-string.h:225 [inline] packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fdfd5954c29 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29 RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005 RBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60 R13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54 </TASK> addr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame: ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246 this frame has 1 object: [32, 160) 'addr' Memory state around the buggy address: ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 >ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 ^ ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1 ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00 ================================================================== | ["https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d","https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02","https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a","https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da","https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33","https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0","https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a","https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2","https://git.kernel.org/stable/c/268dcf1f7b3193bc446ec3d14e08a240e9561e4d","https://git.kernel.org/stable/c/70b7b3c055fd4a464da8da55ff4c1f84269f9b02","https://git.kernel.org/stable/c/a055f5f2841f7522b44a2b1eccb1951b4b03d51a","https://git.kernel.org/stable/c/a33dd1e6693f80d805155b3f69c18c2f642915da","https://git.kernel.org/stable/c/b1e27cda1e3c12b705875bb7e247a97168580e33","https://git.kernel.org/stable/c/b9d5772d60f8e7ef34e290f72fc20e3a4883e7d0","https://git.kernel.org/stable/c/c700525fcc06b05adfea78039de02628af79e07a","https://git.kernel.org/stable/c/ef591b35176029fdefea38e8388ffa371e18f4b2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48845 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: MIPS: smp: fill in sibling and core maps earlier After enabling CONFIG_SCHED_CORE (landed during 5.14 cycle), 2-core 2-thread-per-core interAptiv (CPS-driven) started emitting the following: [ 0.025698] CPU1 revision is: 0001a120 (MIPS interAptiv (multi)) [ 0.048183] ------------[ cut here ]------------ [ 0.048187] WARNING: CPU: 1 PID: 0 at kernel/sched/core.c:6025 sched_core_cpu_starting+0x198/0x240 [ 0.048220] Modules linked in: [ 0.048233] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc3+ #35 b7b319f24073fd9a3c2aa7ad15fb7993eec0b26f [ 0.048247] Stack : 817f0000 00000004 327804c8 810eb050 00000000 00000004 00000000 c314fdd1 [ 0.048278] 830cbd64 819c0000 81800000 817f0000 83070bf4 00000001 830cbd08 00000000 [ 0.048307] 00000000 00000000 815fcbc4 00000000 00000000 00000000 00000000 00000000 [ 0.048334] 00000000 00000000 00000000 00000000 817f0000 00000000 00000000 817f6f34 [ 0.048361] 817f0000 818a3c00 817f0000 00000004 00000000 00000000 4dc33260 0018c933 [ 0.048389] ... [ 0.048396] Call Trace: [ 0.048399] [<8105a7bc>] show_stack+0x3c/0x140 [ 0.048424] [<8131c2a0>] dump_stack_lvl+0x60/0x80 [ 0.048440] [<8108b5c0>] __warn+0xc0/0xf4 [ 0.048454] [<8108b658>] warn_slowpath_fmt+0x64/0x10c [ 0.048467] [<810bd418>] sched_core_cpu_starting+0x198/0x240 [ 0.048483] [<810c6514>] sched_cpu_starting+0x14/0x80 [ 0.048497] [<8108c0f8>] cpuhp_invoke_callback_range+0x78/0x140 [ 0.048510] [<8108d914>] notify_cpu_starting+0x94/0x140 [ 0.048523] [<8106593c>] start_secondary+0xbc/0x280 [ 0.048539] [ 0.048543] ---[ end trace 0000000000000000 ]--- [ 0.048636] Synchronize counters for CPU 1: done. ...for each but CPU 0/boot. Basic debug printks right before the mentioned line say: [ 0.048170] CPU: 1, smt_mask: So smt_mask, which is sibling mask obviously, is empty when entering the function. This is critical, as sched_core_cpu_starting() calculates core-scheduling parameters only once per CPU start, and it's crucial to have all the parameters filled in at that moment (at least it uses cpu_smt_mask() which in fact is `&cpu_sibling_map[cpu]` on MIPS). A bit of debugging led me to that set_cpu_sibling_map() performing the actual map calculation, was being invocated after notify_cpu_start(), and exactly the latter function starts CPU HP callback round (sched_core_cpu_starting() is basically a CPU HP callback). While the flow is same on ARM64 (maps after the notifier, although before calling set_cpu_online()), x86 started calculating sibling maps earlier than starting the CPU HP callbacks in Linux 4.14 (see [0] for the reference). Neither me nor my brief tests couldn't find any potential caveats in calculating the maps right after performing delay calibration, but the WARN splat is now gone. The very same debug prints now yield exactly what I expected from them: [ 0.048433] CPU: 1, smt_mask: 0-1 [0] https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=76ce7cfe35ef | ["https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565","https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7","https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98","https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239","https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a","https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7","https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b","https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808","https://git.kernel.org/stable/c/32813321f18d5432cec1b1a6ecc964f9ea26d565","https://git.kernel.org/stable/c/56eaacb8137ba2071ce48d4e3d91979270e139a7","https://git.kernel.org/stable/c/7315f8538db009605ffba00370678142ef00ac98","https://git.kernel.org/stable/c/94647aec80d03d6914aa664b7b8e103cd9d63239","https://git.kernel.org/stable/c/be538b764a46be1d0700fd3b6e82fb76bd17f13a","https://git.kernel.org/stable/c/c2420bc3333111184cdcb112282d13afe1338dd7","https://git.kernel.org/stable/c/e8ad9ecc406974deb5e7c070f51cc1d09d21dc4b","https://git.kernel.org/stable/c/f2703def339c793674010cc9f01bfe4980231808"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52753 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference of timing generator [Why & How] Check whether assigned timing generator is NULL or not before accessing its funcs to prevent NULL dereference. | ["https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd","https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9","https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68","https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db","https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c","https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6","https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89","https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195","https://git.kernel.org/stable/c/09909f515032fa80b921fd3118efe66b185d10fd","https://git.kernel.org/stable/c/4e497f1acd99075b13605b2e7fa0cba721a2cfd9","https://git.kernel.org/stable/c/6d8653b1a7a8dc938b566ae8c4f373b36e792c68","https://git.kernel.org/stable/c/79b6a90f4f2433312154cd68452b0ba501fa74db","https://git.kernel.org/stable/c/8a06894666e0b462c9316b26ab615cefdd0d676c","https://git.kernel.org/stable/c/b1904ed480cee3f9f4036ea0e36d139cb5fee2d6","https://git.kernel.org/stable/c/df8bc953eed72371e43ca407bd063507f760cf89","https://git.kernel.org/stable/c/eac3e4760aa12159f7f5475d55a67b7933abc195"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52821 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/panel: fix a possible null pointer dereference In versatile_panel_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190","https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4","https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402","https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992","https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229","https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1","https://git.kernel.org/stable/c/2381f6b628b3214f07375e0adf5ce17093c31190","https://git.kernel.org/stable/c/4fa930ba046d20fc1899770396ee11e905fa96e4","https://git.kernel.org/stable/c/79813cd59398015867d51e6d7dcc14d287d4c402","https://git.kernel.org/stable/c/8a9dd36fcb4f3906982b82593393578db4479992","https://git.kernel.org/stable/c/924e5814d1f84e6fa5cb19c6eceb69f066225229","https://git.kernel.org/stable/c/c7dc0aca5962fb37dbea9769dd26ec37813faae1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26978 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: max310x: fix NULL pointer dereference in I2C instantiation When trying to instantiate a max14830 device from userspace: echo max14830 0x60 > /sys/bus/i2c/devices/i2c-2/new_device we get the following error: Unable to handle kernel NULL pointer dereference at virtual address... ... Call trace: max310x_i2c_probe+0x48/0x170 [max310x] i2c_device_probe+0x150/0x2a0 ... Add check for validity of devtype to prevent the error, and abort probe with a meaningful error message. | ["https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110","https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3","https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a","https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a","https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0","https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733","https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735","https://git.kernel.org/stable/c/0d27056c24efd3d63a03f3edfbcfc4827086b110","https://git.kernel.org/stable/c/12609c76b755dbeb1645c0aacc0f0f4743b2eff3","https://git.kernel.org/stable/c/2160ad6861c4a21d3fa553d7b2aaec6634a37f8a","https://git.kernel.org/stable/c/5cd8af02b466e1beeae13e2de3dc58fcc7925e5a","https://git.kernel.org/stable/c/7d271b798add90c6196539167c019d0817285cf0","https://git.kernel.org/stable/c/aeca49661fd02fd56fb026768b580ce301b45733","https://git.kernel.org/stable/c/c45e53c27b78afd6c81fc25608003576f27b5735","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41060 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check bo_va->bo is non-NULL before using it The call to radeon_vm_clear_freed might clear bo_va->bo, so we have to check it before dereferencing it. | ["https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536","https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af","https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3","https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342","https://git.kernel.org/stable/c/e8d3c53c6f1cccea9c03113f06dd39521c228831","https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe","https://git.kernel.org/stable/c/6fb15dcbcf4f212930350eaee174bb60ed40a536","https://git.kernel.org/stable/c/8a500b3a5f0a58c6f99039091fbd715f64f2f8af","https://git.kernel.org/stable/c/a2b201f83971df03c8e81a480b2f2846ae8ce1a3","https://git.kernel.org/stable/c/a9100f17428cb733c4f6fbb132d98bed76318342","https://git.kernel.org/stable/c/f13c96e0e325a057c03f8a47734adb360e112efe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41089 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode(). Add a check to avoid null pointer dereference. | ["https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50","https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad","https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d","https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0","https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843","https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59","https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637","https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51","https://git.kernel.org/stable/c/1c9f2e60150b4f13789064370e37f39e6e060f50","https://git.kernel.org/stable/c/30cbf6ffafbbdd8a6e4e5f0a2e9a9827ee83f3ad","https://git.kernel.org/stable/c/56fc4d3b0bdef691831cd95715a7ca3ebea98b2d","https://git.kernel.org/stable/c/5eecb49a6c268dc229005bf6e8167d4001dc09a0","https://git.kernel.org/stable/c/6d411c8ccc0137a612e0044489030a194ff5c843","https://git.kernel.org/stable/c/6e49a157d541e7e97b815a56f4bdfcbc89844a59","https://git.kernel.org/stable/c/7ece609b0ce7a7ea8acdf512a77d1fee26621637","https://git.kernel.org/stable/c/ffabad4aa91e33ced3c6ae793fb37771b3e9cb51"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41095 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes In nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. | ["https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49","https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389","https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726","https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e","https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714","https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72","https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb","https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8","https://git.kernel.org/stable/c/0d17604f2e44b3df21e218fe8fb3b836d41bac49","https://git.kernel.org/stable/c/259549b2ccf795b7f91f7b5aba47286addcfa389","https://git.kernel.org/stable/c/66edf3fb331b6c55439b10f9862987b0916b3726","https://git.kernel.org/stable/c/9289cd3450d1da3e271ef4b054d4d2932c41243e","https://git.kernel.org/stable/c/bdda5072494f2a7215d94fc4124ad1949a218714","https://git.kernel.org/stable/c/cb751e48bbcffd292090f7882b23b215111b3d72","https://git.kernel.org/stable/c/dbd75f32252508ed6c46c3288a282c301a57ceeb","https://git.kernel.org/stable/c/f95ed0f54b3d3faecae1140ddab854f904a6e7c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42068 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error. | ["https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a","https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8","https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03","https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720","https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a","https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8","https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03","https://git.kernel.org/stable/c/e3540e5a7054d6daaf9a1415a48aacb092112a89","https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720","https://git.kernel.org/stable/c/fdd411af8178edc6b7bf260f8fa4fba1bedd0a6d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42070 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers. | ["https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4","https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f","https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f","https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8","https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf","https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c","https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564","https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007","https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4","https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f","https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa1c2980f","https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8","https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf","https://git.kernel.org/stable/c/7931d32955e09d0a11b1fe0b6aac1bfa061c005c","https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564","https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42077 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba | ["https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a","https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6","https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4","https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687","https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36","https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111","https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a","https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6","https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4","https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687","https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36","https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42082 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller. | ["https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0","https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c","https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54","https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2","https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4","https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4","https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0","https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c","https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54","https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2","https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4","https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46763 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fou: Fix null-ptr-deref in GRO. We observed a null-ptr-deref in fou_gro_receive() while shutting down a host. [0] The NULL pointer is sk->sk_user_data, and the offset 8 is of protocol in struct fou. When fou_release() is called due to netns dismantle or explicit tunnel teardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data. Then, the tunnel socket is destroyed after a single RCU grace period. So, in-flight udp4_gro_receive() could find the socket and execute the FOU GRO handler, where sk->sk_user_data could be NULL. Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL checks in FOU GRO handlers. [0]: BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0 SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1 Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017 RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou] Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42 RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010 RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08 RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002 R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400 R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0 FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) </IRQ> do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626) RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575) Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246 RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900 RDX: ffff93daee800000 RSI: ffff93d ---truncated--- | ["https://git.kernel.org/stable/c/1df42be305fe478ded1ee0c1d775f4ece713483b","https://git.kernel.org/stable/c/231c235d2f7a66f018f172e26ffd47c363f244ef","https://git.kernel.org/stable/c/4494bccb52ffda22ce5a1163a776d970e6229e08","https://git.kernel.org/stable/c/7e4196935069947d8b70b09c1660b67b067e75cb","https://git.kernel.org/stable/c/c46cd6aaca81040deaea3500ba75126963294bd9","https://git.kernel.org/stable/c/d7567f098f54cb53ee3cee1c82e3d0ed9698b6b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46771 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Remove proc entry when dev is unregistered. syzkaller reported a warning in bcm_connect() below. [0] The repro calls connect() to vxcan1, removes vxcan1, and calls connect() with ifindex == 0. Calling connect() for a BCM socket allocates a proc entry. Then, bcm_sk(sk)->bound is set to 1 to prevent further connect(). However, removing the bound device resets bcm_sk(sk)->bound to 0 in bcm_notify(). The 2nd connect() tries to allocate a proc entry with the same name and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking the original proc entry. Since the proc entry is available only for connect()ed sockets, let's clean up the entry when the bound netdev is unregistered. [0]: proc_dir_entry 'can-bcm/2456' already registered WARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375 Modules linked in: CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375 Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48 RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246 RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002 RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0 R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec FS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7fbd708b0e5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d RDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040 R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098 R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 </TASK> remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456' | ["https://git.kernel.org/stable/c/10bfacbd5e8d821011d857bee73310457c9c989a","https://git.kernel.org/stable/c/33ed4ba73caae39f34ab874ba79138badc2c65dd","https://git.kernel.org/stable/c/3b39dc2901aa7a679a5ca981a3de9f8d5658afe8","https://git.kernel.org/stable/c/4377b79323df62eb5d310354f19b4d130ff58d50","https://git.kernel.org/stable/c/5c680022c4e28ba18ea500f3e29f0428271afa92","https://git.kernel.org/stable/c/76fe372ccb81b0c89b6cd2fec26e2f38c958be85","https://git.kernel.org/stable/c/abb0a615569ec008e8a93d9f3ab2d5b418ea94d4","https://git.kernel.org/stable/c/aec92dbebdbec7567d9f56d7c9296a572b8fd849"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46781 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix missing cleanup on rollforward recovery error In an error injection test of a routine for mount-time recovery, KASAN found a use-after-free bug. It turned out that if data recovery was performed using partial logs created by dsync writes, but an error occurred before starting the log writer to create a recovered checkpoint, the inodes whose data had been recovered were left in the ns_dirty_files list of the nilfs object and were not freed. Fix this issue by cleaning up inodes that have read the recovery data if the recovery routine fails midway before the log writer starts. | ["https://git.kernel.org/stable/c/07e4dc2fe000ab008bcfe90be4324ef56b5b4355","https://git.kernel.org/stable/c/1cf1f7e8cd47244fa947d357ef1f642d91e219a3","https://git.kernel.org/stable/c/35a9a7a7d94662146396199b0cfd95f9517cdd14","https://git.kernel.org/stable/c/5787fcaab9eb5930f5378d6a1dd03d916d146622","https://git.kernel.org/stable/c/8e2d1e9d93c4ec51354229361ac3373058529ec4","https://git.kernel.org/stable/c/9d8c3a585d564d776ee60d4aabec59b404be7403","https://git.kernel.org/stable/c/ca92c4bff2833cb30d493b935168d6cccd5c805d","https://git.kernel.org/stable/c/da02f9eb333333b2e4f25d2a14967cff785ac82e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46784 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix error handling in mana_create_txq/rxq's NAPI cleanup Currently napi_disable() gets called during rxq and txq cleanup, even before napi is enabled and hrtimer is initialized. It causes kernel panic. ? page_fault_oops+0x136/0x2b0 ? page_counter_cancel+0x2e/0x80 ? do_user_addr_fault+0x2f2/0x640 ? refill_obj_stock+0xc4/0x110 ? exc_page_fault+0x71/0x160 ? asm_exc_page_fault+0x27/0x30 ? __mmdrop+0x10/0x180 ? __mmdrop+0xec/0x180 ? hrtimer_active+0xd/0x50 hrtimer_try_to_cancel+0x2c/0xf0 hrtimer_cancel+0x15/0x30 napi_disable+0x65/0x90 mana_destroy_rxq+0x4c/0x2f0 mana_create_rxq.isra.0+0x56c/0x6d0 ? mana_uncfg_vport+0x50/0x50 mana_alloc_queues+0x21b/0x320 ? skb_dequeue+0x5f/0x80 | ["https://git.kernel.org/stable/c/386617efacab10bf5bb40bde403467c57cc00470","https://git.kernel.org/stable/c/4982a47154f0b50de81ee0a0b169a3fc74120a65","https://git.kernel.org/stable/c/9178eb8ebcd887ab75e54ac40d538e54bb9c7788","https://git.kernel.org/stable/c/9e0bff4900b5d412a9bafe4baeaa6facd34f671c","https://git.kernel.org/stable/c/b6ecc662037694488bfff7c9fd21c405df8411f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46855 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_socket: fix sk refcount leaks We must put 'sk' reference before returning. | ["https://git.kernel.org/stable/c/1f68e097e20d3c695281a9c6433acc37be47fe11","https://git.kernel.org/stable/c/33c2258bf8cb17fba9e58b111d4c4f4cf43a4896","https://git.kernel.org/stable/c/83e6fb59040e8964888afcaa5612cc1243736715","https://git.kernel.org/stable/c/8b26ff7af8c32cb4148b3e147c52f9e4c695209c","https://git.kernel.org/stable/c/ddc7c423c4a5386bf865474c694b48178efd311a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35998 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb3: fix lock ordering potential deadlock in cifs_sync_mid_result Coverity spotted that the cifs_sync_mid_result function could deadlock "Thread deadlock (ORDER_REVERSAL) lock_order: Calling spin_lock acquires lock TCP_Server_Info.srv_lock while holding lock TCP_Server_Info.mid_lock" Addresses-Coverity: 1590401 ("Thread deadlock (ORDER_REVERSAL)") | ["https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75","https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc","https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f","https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66","https://git.kernel.org/stable/c/699f8958dece132709c0bff6a9700999a2a63b75","https://git.kernel.org/stable/c/8248224ab5b8ca7559b671917c224296a4d671fc","https://git.kernel.org/stable/c/8861fd5180476f45f9e8853db154600469a0284f","https://git.kernel.org/stable/c/c7a4bca289e50bb4b2650f845c41bb3e453f4c66"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35999 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb3: missing lock when picking channel Coverity spotted a place where we should have been holding the channel lock when accessing the ses channel index. Addresses-Coverity: 1582039 ("Data race condition (MISSING_LOCK)") | ["https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e","https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00","https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887","https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729","https://git.kernel.org/stable/c/0fcf7e219448e937681216353c9a58abae6d3c2e","https://git.kernel.org/stable/c/60ab245292280905603bc0d3654f4cf8fceccb00","https://git.kernel.org/stable/c/8094a600245e9b28eb36a13036f202ad67c1f887","https://git.kernel.org/stable/c/98c7ed29cd754ae7475dc7cb3f33399fda902729"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36924 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock. | ["https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd","https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3","https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683","https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f","https://git.kernel.org/stable/c/6503c39398506cadda9f4c81695a9655ca5fb4fd","https://git.kernel.org/stable/c/ded20192dff31c91cef2a04f7e20e60e9bb887d3","https://git.kernel.org/stable/c/e8bf2c05e8ad68e90f9d5889a9e4ef3f6fe00683","https://git.kernel.org/stable/c/ee833d7e62de2b84ed1332d501b67f12e7e5678f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38628 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind. Hang on to the control IDs instead of pointers since those are correctly handled with locks. | ["https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464","https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0","https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09","https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068","https://git.kernel.org/stable/c/1b739388aa3f8dfb63a9fca777e6dfa6912d0464","https://git.kernel.org/stable/c/453d3fa9266e53f85377b911c19b9a4563fa88c0","https://git.kernel.org/stable/c/89e66809684485590ea0b32c3178e42cba36ac09","https://git.kernel.org/stable/c/bea73b58ab67fe581037ad9cdb93c2557590c068"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44938 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: Fix shift-out-of-bounds in dbDiscardAG When searching for the next smaller log2 block, BLKSTOL2() returned 0, causing shift exponent -1 to be negative. This patch fixes the issue by exiting the loop directly when negative shift is found. | ["https://git.kernel.org/stable/c/234e6ea0855cdb5673d54ecaf7dc5c78f3e84630","https://git.kernel.org/stable/c/4de2c04c3acd5b84f50b0d2f8f09e9b2f42374b9","https://git.kernel.org/stable/c/7063b80268e2593e58bee8a8d709c2f3ff93e2f2","https://git.kernel.org/stable/c/bb7c605a754823b86dd74f6537ccb9d38a9dec5a","https://git.kernel.org/stable/c/bd04a149e3a29e7f71b7956ed41dba34e42d539e","https://git.kernel.org/stable/c/f650148b43949ca9e37e820804bb6026fff404f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48887 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Remove rcu locks from user resources User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. | ["https://git.kernel.org/stable/c/7ac9578e45b20e3f3c0c8eb71f5417a499a7226a","https://git.kernel.org/stable/c/a309c7194e8a2f8bd4539b9449917913f6c2cd50"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48909 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix connection leak There's a potential leak issue under following execution sequence : smc_release smc_connect_work if (sk->sk_state == SMC_INIT) send_clc_confirim tcp_abort(); ... sk.sk_state = SMC_ACTIVE smc_close_active switch(sk->sk_state) { ... case SMC_ACTIVE: smc_close_final() // then wait peer closed Unfortunately, tcp_abort() may discard CLC CONFIRM messages that are still in the tcp send buffer, in which case our connection token cannot be delivered to the server side, which means that we cannot get a passive close message at all. Therefore, it is impossible for the to be disconnected at all. This patch tries a very simple way to avoid this issue, once the state has changed to SMC_ACTIVE after tcp_abort(), we can actively abort the smc connection, considering that the state is SMC_INIT before tcp_abort(), abandoning the complete disconnection process should not cause too much problem. In fact, this problem may exist as long as the CLC CONFIRM message is not received by the server. Whether a timer should be added after smc_close_final() needs to be discussed in the future. But even so, this patch provides a faster release for connection in above case, it should also be valuable. | ["https://git.kernel.org/stable/c/2e8d465b83db307f04ad265848f8ab3f78f6918f","https://git.kernel.org/stable/c/80895b6f9154fb22d36fab311ccbb75503a2c87b","https://git.kernel.org/stable/c/9f1c50cf39167ff71dc5953a3234f3f6eeb8fcb5","https://git.kernel.org/stable/c/e98d46ccfa84b35a9e4b1ccdd83961b41a5d7ce5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46811 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box [Why] Coverity reports OVERRUN warning. soc.num_states could be 40. But array range of bw_params->clk_table.entries is 8. [How] Assert if soc.num_states greater than 8. | ["https://git.kernel.org/stable/c/188fd1616ec43033cedbe343b6579e9921e2d898","https://git.kernel.org/stable/c/4003bac784380fed1f94f197350567eaa73a409d","https://git.kernel.org/stable/c/aba188d6f4ebaf52acf13f204db2bd2c22072504"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57980 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix double free in error path If the uvc_status_init() function fails to allocate the int_urb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvc_status_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it. Reviewed by: Ricardo Ribalda <ribalda@chromium.org> | ["https://git.kernel.org/stable/c/3ba8884a56a3eb97c22f0ce0e4dd410d4ca4c277","https://git.kernel.org/stable/c/6c36dcd662ec5276782838660f8533a7cb26be49","https://git.kernel.org/stable/c/87522ef165e5b6de8ef98cc318f3335166a1512c","https://git.kernel.org/stable/c/9232719ac9ce4d5c213cebda23d72aec3e1c4c0d","https://git.kernel.org/stable/c/c6ef3a7fa97ec823a1e1af9085cf13db9f7b3bac","https://git.kernel.org/stable/c/d1f8e69eec91d5a75ef079778a5d0151db2a7f22","https://git.kernel.org/stable/c/d6e5ba2516c5bef87c1fcb8189b6f3cad7c64b2d","https://git.kernel.org/stable/c/d8e63dd7b6683969d3d47c7b8e9635f96d554ad4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58055 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_tcm: Don't free command immediately Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command. | ["https://git.kernel.org/stable/c/16907219ad6763f401700e1b57b2da4f3e07f047","https://git.kernel.org/stable/c/38229c35a6d7875697dfb293356407330cfcd23e","https://git.kernel.org/stable/c/7cb72dc08ed8da60fd6d1f6adf13bf0e6ee0f694","https://git.kernel.org/stable/c/929b69810eec132b284ffd19047a85d961df9e4d","https://git.kernel.org/stable/c/bbb7f49839b57d66ccaf7b5752d9b63d3031dd0a","https://git.kernel.org/stable/c/c225d006a31949d673e646d585d9569bc28feeb9","https://git.kernel.org/stable/c/e6693595bd1b55af62d057a4136a89d5c2ddf0e9","https://git.kernel.org/stable/c/f0c33e7d387ccbb6870e73a43c558fefede06614"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58069 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM read The nvmem interface supports variable buffer sizes, while the regmap interface operates with fixed-size storage. If an nvmem client uses a buffer size less than 4 bytes, regmap_read will write out of bounds as it expects the buffer to point at an unsigned int. Fix this by using an intermediary unsigned int to hold the value. | ["https://git.kernel.org/stable/c/21cd59fcb9952eb7505da2bdfc1eb9c619df3ff4","https://git.kernel.org/stable/c/3ab8c5ed4f84fa20cd16794fe8dc31f633fbc70c","https://git.kernel.org/stable/c/517aedb365f2c94e2d7e0b908ac7127df76203a1","https://git.kernel.org/stable/c/6f2a8ca9a0a38589f52a7f0fb9425b9ba987ae7c","https://git.kernel.org/stable/c/9adefa7b9559d0f21034a5d5ec1b55840c9348b9","https://git.kernel.org/stable/c/c72b7a474d3f445bf0c5bcf8ffed332c78eb28a1","https://git.kernel.org/stable/c/e5536677da803ed54a29a446515c28dce7d3d574","https://git.kernel.org/stable/c/e5e06455760f2995b16a176033909347929d1128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58083 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: Explicitly verify target vCPU is online in kvm_get_vcpu() Explicitly verify the target vCPU is fully online _prior_ to clamping the index in kvm_get_vcpu(). If the index is "bad", the nospec clamping will generate '0', i.e. KVM will return vCPU0 instead of NULL. In practice, the bug is unlikely to cause problems, as it will only come into play if userspace or the guest is buggy or misbehaving, e.g. KVM may send interrupts to vCPU0 instead of dropping them on the floor. However, returning vCPU0 when it shouldn't exist per online_vcpus is problematic now that KVM uses an xarray for the vCPUs array, as KVM needs to insert into the xarray before publishing the vCPU to userspace (see commit c5b077549136 ("KVM: Convert the kvm->vcpus array to a xarray")), i.e. before vCPU creation is guaranteed to succeed. As a result, incorrectly providing access to vCPU0 will trigger a use-after-free if vCPU0 is dereferenced and kvm_vm_ioctl_create_vcpu() bails out of vCPU creation due to an error and frees vCPU0. Commit afb2acb2e3a3 ("KVM: Fix vcpu_array[0] races") papered over that issue, but in doing so introduced an unsolvable teardown conundrum. Preventing accesses to vCPU0 before it's fully online will allow reverting commit afb2acb2e3a3, without re-introducing the vcpu_array[0] UAF race. | ["https://git.kernel.org/stable/c/09d50ccf0b2d739db4a485b08afe7520a4402a63","https://git.kernel.org/stable/c/125da53b3c0c9d7f58353aea0076e9efd6498ba7","https://git.kernel.org/stable/c/1e7381f3617d14b3c11da80ff5f8a93ab14cfc46","https://git.kernel.org/stable/c/5cce2ed69b00e022b5cdf0c49c82986abd2941a8","https://git.kernel.org/stable/c/7c4899239d0f70f88ac42665b3da51678d122480","https://git.kernel.org/stable/c/ca8da90ed1432ff3d000de4f1e2275d4e7d21b96","https://git.kernel.org/stable/c/d817e510662fd1c9797952408d94806f97a5fffd","https://git.kernel.org/stable/c/f2f805ada63b536bc192458a7098388286568ad4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21715 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: davicom: fix UAF in dm9000_drv_remove dm is netdev private data and it cannot be used after free_netdev() call. Using dm after free_netdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function. This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove"). This bug is detected by our static analysis tool. | ["https://git.kernel.org/stable/c/19e65c45a1507a1a2926649d2db3583ed9d55fd9","https://git.kernel.org/stable/c/2013c95df6752d9c88221d0f0f37b6f197969390","https://git.kernel.org/stable/c/5a54367a7c2378c65aaa4d3cfd952f26adef7aa7","https://git.kernel.org/stable/c/7d7d201eb3b766abe590ac0dda7a508b7db3e357","https://git.kernel.org/stable/c/a53cb72043443ac787ec0b5fa17bb3f8ff3d462b","https://git.kernel.org/stable/c/c411f9a5fdc9158e8f7c57eac961d3df3eb4d8ca","https://git.kernel.org/stable/c/c94ab07edc2843e2f3d46dbd82e5c681503aaadf","https://git.kernel.org/stable/c/db79e982c5f9e39ab710cbce55b05f2f5e6f1ca9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21731 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nbd: don't allow reconnect after disconnect Following process can cause nbd_config UAF: 1) grab nbd_config temporarily; 2) nbd_genl_disconnect() flush all recv_work() and release the initial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero 3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work) 4) step 1) release the reference; 5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAF Fix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), so that nbd_genl_reconfigure() will fail. | ["https://git.kernel.org/stable/c/6bef6222a3f6c7adb6396f77f25a3579d821b09a","https://git.kernel.org/stable/c/844b8cdc681612ff24df62cdefddeab5772fadf1","https://git.kernel.org/stable/c/9793bd5ae4bdbdb2dde401a3cab94a6bfd05e302","https://git.kernel.org/stable/c/a8ee6ecde2b7bfb58c8a3afe8a9d2b848f580739","https://git.kernel.org/stable/c/d208d2c52b652913b5eefc8ca434b0d6b757f68f","https://git.kernel.org/stable/c/e3be8862d73cac833e0fb7602636c19c6cb94b11","https://git.kernel.org/stable/c/e70a578487a47d7cf058904141e586684d1c3381","https://git.kernel.org/stable/c/e7343fa33751cb07c1c56b666bf37cfca357130e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21753 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free when attempting to join an aborted transaction When we are trying to join the current transaction and if it's aborted, we read its 'aborted' field after unlocking fs_info->trans_lock and without holding any extra reference count on it. This means that a concurrent task that is aborting the transaction may free the transaction before we read its 'aborted' field, leading to a use-after-free. Fix this by reading the 'aborted' field while holding fs_info->trans_lock since any freeing task must first acquire that lock and set fs_info->running_transaction to NULL before freeing the transaction. This was reported by syzbot and Dmitry with the following stack traces from KASAN: ================================================================== BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_data_space Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 worker_thread+0x870/0xd30 kernel/workqueue.c:3398 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5315: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 lookup_open fs/namei.c:3649 [inline] open_last_lookups fs/namei.c:3748 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3984 do_filp_open+0x27f/0x4e0 fs/namei.c:4014 do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 do_sys_open fs/open.c:1417 [inline] __do_sys_creat fs/open.c:1495 [inline] __se_sys_creat fs/open.c:1489 [inline] __x64_sys_creat+0x123/0x170 fs/open.c:1489 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 5336: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 cleanup_transaction fs/btrfs/transaction.c:2063 [inline] btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 btrfs_balance+0x992/ ---truncated--- | ["https://git.kernel.org/stable/c/6ba4663ada6c6315af23a6669d386146634808ec","https://git.kernel.org/stable/c/7e954b6bb95d67ae4d1a20e9cfd83c182cf929bc","https://git.kernel.org/stable/c/86d71a026a7f63da905db9add845c8ee88801eca","https://git.kernel.org/stable/c/8f5cff471039caa2b088060c074c2bf2081bcb01","https://git.kernel.org/stable/c/c7a53757717e68af94a56929d57f1e6daff220ec","https://git.kernel.org/stable/c/ce628048390dad80320d5a1f74de6ca1e1be91e7","https://git.kernel.org/stable/c/cee55b1219568c80bf0d5dc55066e4a859baf753","https://git.kernel.org/stable/c/e2f0943cf37305dbdeaf9846e3c941451bcdef63"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21760 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ndisc: extend RCU protection in ndisc_send_skb() ndisc_send_skb() can be called without RTNL or RCU held. Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu() and avoid a potential UAF. | ["https://git.kernel.org/stable/c/04e05112f10354ffc3bb6cc796d553bab161594c","https://git.kernel.org/stable/c/10a1f3fece2f0d23a3a618b72b2b4e6f408ef7d1","https://git.kernel.org/stable/c/4d576202b90b1b95a7c428a80b536f91b8201bcc","https://git.kernel.org/stable/c/789230e5a8c1097301afc802e242c79bc8835c67","https://git.kernel.org/stable/c/a9319d800b5701e7f5e3fa71a5b7c4831fc20d6d","https://git.kernel.org/stable/c/ae38982f521621c216fc2f5182cd091f4734641d","https://git.kernel.org/stable/c/e24d225e4cb8cf108bde00b76594499b98f0a74d","https://git.kernel.org/stable/c/ed6ae1f325d3c43966ec1b62ac1459e2b8e45640"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21761 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: openvswitch: use RCU protection in ovs_vport_cmd_fill_info() ovs_vport_cmd_fill_info() can be called without RTNL or RCU. Use RCU protection and dev_net_rcu() to avoid potential UAF. | ["https://git.kernel.org/stable/c/5828937742af74666192835d657095d95c53dbd0","https://git.kernel.org/stable/c/7e01abc34e87abd091e619161a20f54ed4e3e2da","https://git.kernel.org/stable/c/8ec57509c36c8b9a23e50b7858dda0c520a2d074","https://git.kernel.org/stable/c/90b2f49a502fa71090d9f4fe29a2f51fe5dff76d","https://git.kernel.org/stable/c/a849a10de5e04d798f7f286a2f1ca174719a617a","https://git.kernel.org/stable/c/a8816b3f1f151373fd30f1996f00480126c8bb11","https://git.kernel.org/stable/c/a884f57600e463f69d7b279c4598b865260b62a1","https://git.kernel.org/stable/c/e85a25d1a9985645e796039e843d1de581d2de1e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21762 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arp: use RCU protection in arp_xmit() arp_xmit() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF. | ["https://git.kernel.org/stable/c/01d1b5c9abcaff29a43f1d17a19c33eec92c7dbe","https://git.kernel.org/stable/c/10f555e3f573d004ae9d89b3276abb58c4ede5c3","https://git.kernel.org/stable/c/2c331718d3389b6c5f6855078ab7171849e016bd","https://git.kernel.org/stable/c/307cd1e2d3cb1cbc6c40c679cada6d7168b18431","https://git.kernel.org/stable/c/a42b69f692165ec39db42d595f4f65a4c8f42e44","https://git.kernel.org/stable/c/d9366ac2f956a1948b68c0500f84a3462ff2ed8a","https://git.kernel.org/stable/c/e9f4dee534eb1b225b0a120395ad9bc2afe164d3","https://git.kernel.org/stable/c/f189654459423d4d48bef2d120b4bfba559e6039"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21763 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: neighbour: use RCU protection in __neigh_notify() __neigh_notify() can be called without RTNL or RCU protection. Use RCU protection to avoid potential UAF. | ["https://git.kernel.org/stable/c/1cbb2aa90cd3fba15ad7efb5cdda28f3d1082379","https://git.kernel.org/stable/c/40d8f2f2a373b6c294ffac394d2bb814b572ead1","https://git.kernel.org/stable/c/559307d25235e24b5424778c7332451b6c741159","https://git.kernel.org/stable/c/784eb2376270e086f7db136d154b8404edacf97b","https://git.kernel.org/stable/c/8666e9aab801328c1408a19fbf4070609dc0695a","https://git.kernel.org/stable/c/becbd5850c03ed33b232083dd66c6e38c0c0e569","https://git.kernel.org/stable/c/cdd5c2a12ddad8a77ce1838ff9f29aa587de82df","https://git.kernel.org/stable/c/e1aed6be381bcd7f46d4ca9d7ef0f5f3d6a1be32"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21764 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ndisc: use RCU protection in ndisc_alloc_skb() ndisc_alloc_skb() can be called without RTNL or RCU being held. Add RCU protection to avoid possible UAF. | ["https://git.kernel.org/stable/c/3c2d705f5adf5d860aaef90cb4211c0fde2ba66d","https://git.kernel.org/stable/c/628e6d18930bbd21f2d4562228afe27694f66da9","https://git.kernel.org/stable/c/96fc896d0e5b37c12808df797397fb16f3080879","https://git.kernel.org/stable/c/9e0ec817eb41a55327a46cd3ce331a9868d60304","https://git.kernel.org/stable/c/b870256dd2a5648d5ed2f22316b3ac29a7e5ed63","https://git.kernel.org/stable/c/bbec88e4108e8d6fb468d3817fa652140a44ff28","https://git.kernel.org/stable/c/c30893ef3d9cde8e7e8e4fd06b53d2c935bbccb1","https://git.kernel.org/stable/c/cd1065f92eb7ff21b9ba5308a86f33d1670bf926"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53171 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit After an insertion in TNC, the tree might split and cause a node to change its `znode->parent`. A further deletion of other nodes in the tree (which also could free the nodes), the aforementioned node's `znode->cparent` could still point to a freed node. This `znode->cparent` may not be updated when getting nodes to commit in `ubifs_tnc_start_commit()`. This could then trigger a use-after-free when accessing the `znode->cparent` in `write_index()` in `ubifs_tnc_end_commit()`. This can be triggered by running rm -f /etc/test-file.bin dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync in a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then reports: BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950 Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153 Call trace: dump_backtrace+0x0/0x340 show_stack+0x18/0x24 dump_stack_lvl+0x9c/0xbc print_address_description.constprop.0+0x74/0x2b0 kasan_report+0x1d8/0x1f0 kasan_check_range+0xf8/0x1a0 memcpy+0x84/0xf4 ubifs_tnc_end_commit+0xa5c/0x1950 do_commit+0x4e0/0x1340 ubifs_bg_thread+0x234/0x2e0 kthread+0x36c/0x410 ret_from_fork+0x10/0x20 Allocated by task 401: kasan_save_stack+0x38/0x70 __kasan_kmalloc+0x8c/0xd0 __kmalloc+0x34c/0x5bc tnc_insert+0x140/0x16a4 ubifs_tnc_add+0x370/0x52c ubifs_jnl_write_data+0x5d8/0x870 do_writepage+0x36c/0x510 ubifs_writepage+0x190/0x4dc __writepage+0x58/0x154 write_cache_pages+0x394/0x830 do_writepages+0x1f0/0x5b0 filemap_fdatawrite_wbc+0x170/0x25c file_write_and_wait_range+0x140/0x190 ubifs_fsync+0xe8/0x290 vfs_fsync_range+0xc0/0x1e4 do_fsync+0x40/0x90 __arm64_sys_fsync+0x34/0x50 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 Freed by task 403: kasan_save_stack+0x38/0x70 kasan_set_track+0x28/0x40 kasan_set_free_info+0x28/0x4c __kasan_slab_free+0xd4/0x13c kfree+0xc4/0x3a0 tnc_delete+0x3f4/0xe40 ubifs_tnc_remove_range+0x368/0x73c ubifs_tnc_remove_ino+0x29c/0x2e0 ubifs_jnl_delete_inode+0x150/0x260 ubifs_evict_inode+0x1d4/0x2e4 evict+0x1c8/0x450 iput+0x2a0/0x3c4 do_unlinkat+0x2cc/0x490 __arm64_sys_unlinkat+0x90/0x100 invoke_syscall.constprop.0+0xa8/0x260 do_el0_svc+0xc8/0x1f0 el0_svc+0x34/0x70 el0t_64_sync_handler+0x108/0x114 el0t_64_sync+0x1a4/0x1a8 The offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free when a node becomes root in TNC but still has a `cparent` to an already freed node. More specifically, consider the following TNC: zroot / / zp1 / / zn Inserting a new node `zn_new` with a key smaller then `zn` will trigger a split in `tnc_insert()` if `zp1` is full: zroot / \ / \ zp1 zp2 / \ / \ zn_new zn `zn->parent` has now been moved to `zp2`, *but* `zn->cparent` still points to `zp1`. Now, consider a removal of all the nodes _except_ `zn`. Just when `tnc_delete()` is about to delete `zroot` and `zp2`: zroot \ \ zp2 \ \ zn `zroot` and `zp2` get freed and the tree collapses: zn `zn` now becomes the new `zroot`. `get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and `write_index()` will check its `znode->cparent` that wrongly points to the already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called with `znode->cparent->zbranch[znode->iip].hash` that triggers the use-after-free! Fix this by explicitly setting `znode->cparent` to `NULL` in `get_znodes_to_commit()` for the root node. The search for the dirty nodes ---truncated--- | ["https://git.kernel.org/stable/c/01d3a2293d7e4edfff96618c15727db7e51f11b6","https://git.kernel.org/stable/c/2497479aecebe869d23a0064e0fd1a03e34f0e2a","https://git.kernel.org/stable/c/398a91599d263e41c5f95a2fd4ebdb6280b5c6c3","https://git.kernel.org/stable/c/4617fb8fc15effe8eda4dd898d4e33eb537a7140","https://git.kernel.org/stable/c/4d9807048b851d7a58d5bd089c16254af896e4df","https://git.kernel.org/stable/c/74981f7577d183acad1cd58f74c10d263711a215","https://git.kernel.org/stable/c/8d8b3f5f4cbfbf6cb0ea4a4d5dc296872b4151eb","https://git.kernel.org/stable/c/daac4aa1825de0dbc1a6eede2fa7f9fc53f14223"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57795 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Remove the direct link to net_device The similar patch in siw is in the link: https://git.kernel.org/rdma/rdma/c/16b87037b48889 This problem also occurred in RXE. The following analyze this problem. In the following Call Traces: " BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295 CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted 6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: infiniband ib_cache_event_task Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> " 1). In the link [1], " infiniband syz2: set down " This means that on 839.350575, the event ib_cache_event_task was sent andi queued in ib_wq. 2). In the link [1], " team0 (unregistering): Port device team_slave_0 removed " It indicates that before 843.251853, the net device should be freed. 3). In the link [1], " BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 " This means that on 850.559070, this slab-use-after-free problem occurred. In all, on 839.350575, the event ib_cache_event_task was sent and queued in ib_wq, before 843.251853, the net device veth was freed. on 850.559070, this event was executed, and the mentioned freed net device was called. Thus, the above call trace occurred. [1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000 | ["https://git.kernel.org/stable/c/2ac5415022d16d63d912a39a06f32f1f51140261","https://git.kernel.org/stable/c/9f6f54e6a6863131442b40e14d1792b090c7ce21"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57857 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Remove direct link to net_device Do not manage a per device direct link to net_device. Rely on associated ib_devices net_device management, not doubling the effort locally. A badly managed local link to net_device was causing a 'KASAN: slab-use-after-free' exception during siw_query_port() call. | ["https://git.kernel.org/stable/c/16b87037b48889d21854c8e97aec8a1baf2642b3","https://git.kernel.org/stable/c/4eafeb4f021c50d13f199239d913b37de3c83135"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49859 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it. | ["https://git.kernel.org/stable/c/10569b682ebe9c75ef06ddd322ae844e9be6374b","https://git.kernel.org/stable/c/26b07bd2e1f124b0e430c8d250023f7205c549c3","https://git.kernel.org/stable/c/7cb51731f24b216b0b87942f519f2c67a17107ee","https://git.kernel.org/stable/c/bfe5c02654261bfb8bd9cb174a67f3279ea99e58","https://git.kernel.org/stable/c/d6f08c88047accc6127dddb6798a3ff11321539d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3714 | Medium | N/A | A flaw was found in the Linux kernels memory deduplication mechanism. Previous work has shown that memory deduplication can be attacked via a local exploitation mechanism. The same technique can be used if an attacker can upload page sized files and detect the change in access time from a networked service to determine if the page has been merged. | ["https://access.redhat.com/security/cve/CVE-2021-3714","https://arxiv.org/abs/2111.08553","https://arxiv.org/pdf/2111.08553.pdf","https://bugzilla.redhat.com/show_bug.cgi?id=1931327","https://access.redhat.com/security/cve/CVE-2021-3714","https://arxiv.org/abs/2111.08553","https://arxiv.org/pdf/2111.08553.pdf","https://bugzilla.redhat.com/show_bug.cgi?id=1931327"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50256 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated--- | ["https://git.kernel.org/stable/c/4ed234fe793f27a3b151c43d2106df2ff0d81aac","https://git.kernel.org/stable/c/4f7b586aae53c2ed820661803da8ce18b1361921","https://git.kernel.org/stable/c/f85b057e34419e5ec0583a65078a11ccc1d4540a","https://git.kernel.org/stable/c/fef63832317d9d24e1214cdd8f204d02ebdf8499"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57973 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rdma/cxgb4: Prevent potential integer overflow on 32bit The "gl->tot_len" variable is controlled by the user. It comes from process_responses(). On 32bit systems, the "gl->tot_len + sizeof(struct cpl_pass_accept_req) + sizeof(struct rss_header)" addition could have an integer wrapping bug. Use size_add() to prevent this. | ["https://git.kernel.org/stable/c/2b759f78b83221f4a1cae3aeb20b500e375f3ee6","https://git.kernel.org/stable/c/4422f452d028850b9cc4fd8f1cf45a8ff91855eb","https://git.kernel.org/stable/c/aeb814484387811b3579d5c78ad4eb301e3bf1c8","https://git.kernel.org/stable/c/bd96a3935e89486304461a21752f824fc25e0f0b","https://git.kernel.org/stable/c/d64148a10a85952352de6091ceed99fb9ce2d3ee","https://git.kernel.org/stable/c/dd352107f22bfbecbbf3b74bde14f3f932296309","https://git.kernel.org/stable/c/de8d88b68d0cfd41152a7a63d6aec0ed3e1b837a","https://git.kernel.org/stable/c/e53ca458f543aa352d09b484550de173cb9085c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57981 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix NULL pointer dereference on certain command aborts If a command is queued to the final usable TRB of a ring segment, the enqueue pointer is advanced to the subsequent link TRB and no further. If the command is later aborted, when the abort completion is handled the dequeue pointer is advanced to the first TRB of the next segment. If no further commands are queued, xhci_handle_stopped_cmd_ring() sees the ring pointers unequal and assumes that there is a pending command, so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL. Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbell ring likely is unnecessary too, but it's harmless. Leave it alone. This is probably Bug 219532, but no confirmation has been received. The issue has been independently reproduced and confirmed fixed using a USB MCU programmed to NAK the Status stage of SET_ADDRESS forever. Everything continued working normally after several prevented crashes. | ["https://git.kernel.org/stable/c/0ce5c0dac768be14afe2426101b568a0f66bfc4d","https://git.kernel.org/stable/c/1e0a19912adb68a4b2b74fd77001c96cd83eb073","https://git.kernel.org/stable/c/4ff18870af793ce2034a6ad746e91d0a3d985b88","https://git.kernel.org/stable/c/ae069cd2ba09a2bd6a87a68c59ef0b7ea39cd641","https://git.kernel.org/stable/c/b44253956407046e5907d4d72c8fa5b93ae94485","https://git.kernel.org/stable/c/b649f0d5bc256f691c7d234c3986685d54053de1","https://git.kernel.org/stable/c/cf30300a216a4f8dce94e11781a866a09d4b50d4","https://git.kernel.org/stable/c/fd8bfaeba4a85b14427899adec0efb3954300653"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58052 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_table The function atomctrl_get_smc_sclk_range_table() does not check the return value of smu_atom_get_data_table(). If smu_atom_get_data_table() fails to retrieve SMU_Info table, it returns NULL which is later dereferenced. Found by Linux Verification Center (linuxtesting.org) with SVACE. In practice this should never happen as this code only gets called on polaris chips and the vbios data table will always be present on those chips. | ["https://git.kernel.org/stable/c/0b97cd8a61b2b40fd73cf92a4bb2256462d22adb","https://git.kernel.org/stable/c/2396bc91935c6da0588ce07850d07897974bd350","https://git.kernel.org/stable/c/357445e28ff004d7f10967aa93ddb4bffa5c3688","https://git.kernel.org/stable/c/396350adf0e5ad4bf05f01e4d79bfb82f0f6c41a","https://git.kernel.org/stable/c/6a30634a2e0f1dd3c6b39fd0f114c32893a9907a","https://git.kernel.org/stable/c/a713ba7167c2d74c477dd7764dbbdbe3199f17f4","https://git.kernel.org/stable/c/ae522ad211ec4b72eaf742b25f24b0a406afcba1","https://git.kernel.org/stable/c/c47066ed7c8f3b320ef87fa6217a2b8b24e127cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58058 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubifs: skip dumping tnc tree when zroot is null Clearing slab cache will free all znode in memory and make c->zroot.znode = NULL, then dumping tnc tree will access c->zroot.znode which cause null pointer dereference. | ["https://git.kernel.org/stable/c/1787cd67bb94b106555ffe64f887f6aa24b47010","https://git.kernel.org/stable/c/2a987950df825d0144370e700dc5fb337684ffba","https://git.kernel.org/stable/c/40e25a3c0063935763717877bb2a814c081509ff","https://git.kernel.org/stable/c/428aff8f7cfb0d9a8854477648022cef96bcab28","https://git.kernel.org/stable/c/6211c11fc20424bbc6d79c835c7c212b553ae898","https://git.kernel.org/stable/c/77e5266e3d3faa6bdcf20d9c68a8972f6aa06522","https://git.kernel.org/stable/c/bdb0ca39e0acccf6771db49c3f94ed787d05f2d7","https://git.kernel.org/stable/c/e01b55f261ccc96e347eba4931e4429d080d879d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58063 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory"). | ["https://git.kernel.org/stable/c/32acebca0a51f5e372536bfdc0d7d332ab749013","https://git.kernel.org/stable/c/455e0f40b5352186a9095f2135d5c89255e7c39a","https://git.kernel.org/stable/c/624cea89a0865a2bc3e00182a6b0f954a94328b4","https://git.kernel.org/stable/c/6b76bab5c257463302c9e97f5d84d524457468eb","https://git.kernel.org/stable/c/85b67b4c4a0f8a6fb20cf4ef7684ff2b0cf559df","https://git.kernel.org/stable/c/b96371339fd9cac90f5ee4ac17ee5c4cbbdfa6f7","https://git.kernel.org/stable/c/e7ceefbfd8d447abc8aca8ab993a942803522c06","https://git.kernel.org/stable/c/ee0b0d7baa8a6d42c7988f6e50c8f164cdf3fa47"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21736 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix possible int overflows in nilfs_fiemap() Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result by being prepared to go through potentially maxblocks == INT_MAX blocks, the value in n may experience an overflow caused by left shift of blkbits. While it is extremely unlikely to occur, play it safe and cast right hand expression to wider type to mitigate the issue. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. | ["https://git.kernel.org/stable/c/250423300b4b0335918be187ef3cade248c06e6a","https://git.kernel.org/stable/c/58b1c6881081f5ddfb9a14dc241a74732c0f855c","https://git.kernel.org/stable/c/6438ef381c183444f7f9d1de18f22661cba1e946","https://git.kernel.org/stable/c/7649937987fed51ed09985da4019d50189fc534e","https://git.kernel.org/stable/c/8f41df5fd4c11d26e929a85f7239799641f92da7","https://git.kernel.org/stable/c/b9495a9109abc31d3170f7aad7d48aa64610a1a2","https://git.kernel.org/stable/c/f2bd0f1ab47822fe5bd699c8458b896c4b2edea1","https://git.kernel.org/stable/c/f3d80f34f58445355fa27b9579a449fb186aa64e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21744 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize() On removal of the device or unloading of the kernel module a potential NULL pointer dereference occurs. The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if() Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated to BRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches. After brcmf_remove_interface() call the brcmf_proto_detach() function is called providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize() Since brcmf_get_ip() can and actually will return NULL in this case the call to brcmf_txfinalize() will result in a NULL pointer dereference inside brcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors. This will only happen if a flowring still has an skb. Although the NULL pointer dereference has only been seen when trying to update the tx statistic, all other uses of the ifp pointer have been guarded as well with an early return if ifp is NULL. | ["https://git.kernel.org/stable/c/2326e19190e176fd72bb542b837a9d2b7fcb8693","https://git.kernel.org/stable/c/3877fc67bd3d5566cc12763bce39710ceb74a97d","https://git.kernel.org/stable/c/4e51d6d093e763348916e69d06d87e0a5593661b","https://git.kernel.org/stable/c/59ff4fa653ff6db07c61152516ffba79c2a74bda","https://git.kernel.org/stable/c/61541d9b5a23df33934fcc620a3a81f246b1b240","https://git.kernel.org/stable/c/68abd0c4ebf24cd499841a488b97a6873d5efabb","https://git.kernel.org/stable/c/a2beefc4fa49ebc22e664dc6b39dbd054f8488f9","https://git.kernel.org/stable/c/fbbfef2a5b858eab55741a58b2ac9a0cc8d53c58"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21776 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: hub: Ignore non-compliant devices with too many configs or interfaces Robert Morris created a test program which can cause usb_hub_to_struct_hub() to dereference a NULL or inappropriate pointer: Oops: general protection fault, probably for non-canonical address 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14 Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110 ... Call Trace: <TASK> ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0 The cause of this error is that the device has two interfaces, and the hub driver binds to interface 1 instead of interface 0, which is where usb_hub_to_struct_hub() looks. We can prevent the problem from occurring by refusing to accept hub devices that violate the USB spec by having more than one configuration or interface. | ["https://git.kernel.org/stable/c/2240fed37afbcdb5e8b627bc7ad986891100e05d","https://git.kernel.org/stable/c/49f077106fa07919a6a6dda99bb490dd1d1a8218","https://git.kernel.org/stable/c/5b9778e1fe715700993ce436c152dc3b7df0b490","https://git.kernel.org/stable/c/62d8f4c5454dd39aded4f343720d1c5a1803cfef","https://git.kernel.org/stable/c/c3720b04df84b5459050ae4e03ec7d545652f897","https://git.kernel.org/stable/c/d343fe0fad5c1d689775f2dda24a85ce98e29566","https://git.kernel.org/stable/c/d3a67adb365cdfdac4620daf38a82e57ca45806c","https://git.kernel.org/stable/c/e905a0fca7bff0855d312c16f71e60e1773b393e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21787 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: team: better TEAM_OPTION_TYPE_STRING validation syzbot reported following splat [1] Make sure user-provided data contains one nul byte. [1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/4236bf4716589558cc0f3c3612642b2c2141b04e","https://git.kernel.org/stable/c/4512482e4805dd30bc77dec511f2a2edba5cb868","https://git.kernel.org/stable/c/5bef3ac184b5626ea62385d6b82a1992b89d7940","https://git.kernel.org/stable/c/7c30483d0f6bdb2230e10e3e4be5167927eac7a0","https://git.kernel.org/stable/c/7f5af50f3aa0af8cbef9fb76fffeed69e8143f59","https://git.kernel.org/stable/c/8401cade1918281177974b32c925afdce750d292","https://git.kernel.org/stable/c/d071a91fa614ecdf760c29f61f6a7bfb7df796d6","https://git.kernel.org/stable/c/f443687ad20c70320d1248f35f57bf46cac8df0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21846 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: acct: perform last write from workqueue In [1] it was reported that the acct(2) system call can be used to trigger NULL deref in cases where it is set to write to a file that triggers an internal lookup. This can e.g., happen when pointing acc(2) to /sys/power/resume. At the point the where the write to this file happens the calling task has already exited and called exit_fs(). A lookup will thus trigger a NULL-deref when accessing current->fs. Reorganize the code so that the the final write happens from the workqueue but with the caller's credentials. This preserves the (strange) permission model and has almost no regression risk. This api should stop to exist though. | ["https://git.kernel.org/stable/c/56d5f3eba3f5de0efdd556de4ef381e109b973a9","https://git.kernel.org/stable/c/5a59ced8ffc71973d42c82484a719c8f6ac8f7f7","https://git.kernel.org/stable/c/5c928e14a2ccd99462f2351ead627b58075bb736","https://git.kernel.org/stable/c/5d5b936cfa4b0d5670ca7420ef165a074bc008eb","https://git.kernel.org/stable/c/5ee8da9bea70dda492d61f075658939af33d8410","https://git.kernel.org/stable/c/8acbf4a88c6a98c8ed00afd1a7d1abcca9b4735e","https://git.kernel.org/stable/c/a8136afca090412a36429cb6c2543c714d9c0f84","https://git.kernel.org/stable/c/b03782ae707cc45e65242c7cddd8e28f1c22cde5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21866 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 <VEC,EE,PR,FP,ME,IR,DR,RI> CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet. Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area. That went undetected until commit e4137f08816b ("mm, kasan, kmsan: instrument copy_from/to_kernel_nofault") The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately. | ["https://git.kernel.org/stable/c/2d542f13d26344e3452eee77613026ce9b653065","https://git.kernel.org/stable/c/2e6c80423f201405fd65254e52decd21663896f3","https://git.kernel.org/stable/c/6847b3e40bb963e57b61d1cc6fe84cb37b9d3d4c","https://git.kernel.org/stable/c/8d06e9208184b2851fa79a3a39d6860320c8bdf8","https://git.kernel.org/stable/c/97de5852058a299ba447cd9782fe96488d30108b","https://git.kernel.org/stable/c/c905a3053518212a1017e50bd2be3bee59305bb0","https://git.kernel.org/stable/c/d262a192d38e527faa5984629aabda2e0d1c4f54","https://git.kernel.org/stable/c/f8d4c5b653c1bc0df56e15658bbf64fc359adc4e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26960 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: swap: fix race between free_swap_and_cache() and swapoff() There was previously a theoretical window where swapoff() could run and teardown a swap_info_struct while a call to free_swap_and_cache() was running in another thread. This could cause, amongst other bad possibilities, swap_page_trans_huge_swapped() (called by free_swap_and_cache()) to access the freed memory for swap_map. This is a theoretical problem and I haven't been able to provoke it from a test case. But there has been agreement based on code review that this is possible (see link below). Fix it by using get_swap_device()/put_swap_device(), which will stall swapoff(). There was an extra check in _swap_info_get() to confirm that the swap entry was not free. This isn't present in get_swap_device() because it doesn't make sense in general due to the race between getting the reference and swapoff. So I've added an equivalent check directly in free_swap_and_cache(). Details of how to provoke one possible issue (thanks to David Hildenbrand for deriving this): --8<----- __swap_entry_free() might be the last user and result in "count == SWAP_HAS_CACHE". swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0. So the question is: could someone reclaim the folio and turn si->inuse_pages==0, before we completed swap_page_trans_huge_swapped(). Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are still references by swap entries. Process 1 still references subpage 0 via swap entry. Process 2 still references subpage 1 via swap entry. Process 1 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE [then, preempted in the hypervisor etc.] Process 2 quits. Calls free_swap_and_cache(). -> count == SWAP_HAS_CACHE Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls __try_to_reclaim_swap(). __try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()-> put_swap_folio()->free_swap_slot()->swapcache_free_entries()-> swap_entry_free()->swap_range_free()-> ... WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries); What stops swapoff to succeed after process 2 reclaimed the swap cache but before process1 finished its call to swap_page_trans_huge_swapped()? --8<----- | ["https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a","https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a","https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e","https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b","https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39","https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e","https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d","https://git.kernel.org/stable/c/0f98f6d2fb5fad00f8299b84b85b6bc1b6d7d19a","https://git.kernel.org/stable/c/1ede7f1d7eed1738d1b9333fd1e152ccb450b86a","https://git.kernel.org/stable/c/2da5568ee222ce0541bfe446a07998f92ed1643e","https://git.kernel.org/stable/c/363d17e7f7907c8e27a9e86968af0eaa2301787b","https://git.kernel.org/stable/c/3ce4c4c653e4e478ecb15d3c88e690f12cbf6b39","https://git.kernel.org/stable/c/82b1c07a0af603e3c47b906c8e991dc96f01688e","https://git.kernel.org/stable/c/d85c11c97ecf92d47a4b29e3faca714dc1f18d0d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27072 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Remove useless locks in usbtv_video_free() Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop() call since it will be called when unregistering the device. Before 'c838530d230b' this issue would only be noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not streaming. [hverkuil: fix minor spelling mistake in log message] | ["https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2","https://git.kernel.org/stable/c/4ec4641df57cbdfdc51bb4959afcdbcf5003ddb9","https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895","https://git.kernel.org/stable/c/bdd82c47b22a8befd617b723098b2a41b77373c7","https://git.kernel.org/stable/c/d5ed208d04acf06781d63d30f9fa991e8d609ebd","https://git.kernel.org/stable/c/dea46e246ef0f98d89d59a4229157cd9ffb636bf","https://git.kernel.org/stable/c/3e7d82ebb86e94643bdb30b0b5b077ed27dce1c2","https://git.kernel.org/stable/c/65e6a2773d655172143cc0b927cdc89549842895"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35895 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Prevent lock inversion deadlock in map delete elem syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a map_delete_elem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep: CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); local_irq_disable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock); Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context. Detect when map_delete_elem operation is invoked from a context which is _not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an error. Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today. | ["https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86","https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd","https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5","https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec","https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75","https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058","https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48","https://git.kernel.org/stable/c/668b3074aa14829e2ac2759799537a93b60fef86","https://git.kernel.org/stable/c/6af057ccdd8e7619960aca1f0428339f213b31cd","https://git.kernel.org/stable/c/a44770fed86515eedb5a7c00b787f847ebb134a5","https://git.kernel.org/stable/c/d1e73fb19a4c872d7a399ad3c66e8ca30e0875ec","https://git.kernel.org/stable/c/dd54b48db0c822ae7b520bc80751f0a0a173ef75","https://git.kernel.org/stable/c/f7990498b05ac41f7d6a190dc0418ef1d21bf058","https://git.kernel.org/stable/c/ff91059932401894e6c86341915615c5eb0eca48","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35990 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma: xilinx_dpdma: Fix locking There are several places where either chan->lock or chan->vchan.lock was not held. Add appropriate locking. This fixes lockdep warnings like [ 31.077578] ------------[ cut here ]------------ [ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.077953] Modules linked in: [ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98 [ 31.078102] Hardware name: xlnx,zynqmp (DT) [ 31.078169] Workqueue: events_unbound deferred_probe_work_func [ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0 [ 31.078550] sp : ffffffc083bb2e10 [ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168 [ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480 [ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000 [ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000 [ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001 [ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def [ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516 [ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff [ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000 [ 31.080307] Call trace: [ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0 [ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120 [ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac [ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c [ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684 [ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0 [ 31.081139] commit_tail+0x234/0x294 [ 31.081246] drm_atomic_helper_commit+0x1f8/0x210 [ 31.081363] drm_atomic_commit+0x100/0x140 [ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384 [ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c [ 31.081725] drm_client_modeset_commit+0x34/0x5c [ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168 [ 31.081899] drm_fb_helper_set_par+0x50/0x70 [ 31.081971] fbcon_init+0x538/0xc48 [ 31.082047] visual_init+0x16c/0x23c [ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634 [ 31.082320] do_take_over_console+0x24c/0x33c [ 31.082429] do_fbcon_takeover+0xbc/0x1b0 [ 31.082503] fbcon_fb_registered+0x2d0/0x34c [ 31.082663] register_framebuffer+0x27c/0x38c [ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c [ 31.082939] drm_fb_helper_initial_config+0x50/0x74 [ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108 [ 31.083115] drm_client_register+0xa0/0xf4 [ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc [ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0 [ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0 [ 31.083616] platform_probe+0x8c/0x13c [ 31.083713] really_probe+0x258/0x59c [ 31.083793] __driver_probe_device+0xc4/0x224 [ 31.083878] driver_probe_device+0x70/0x1c0 [ 31.083961] __device_attach_driver+0x108/0x1e0 [ 31.084052] bus_for_each_drv+0x9c/0x100 [ 31.084125] __device_attach+0x100/0x298 [ 31.084207] device_initial_probe+0x14/0x20 [ 31.084292] bus_probe_device+0xd8/0xdc [ 31.084368] deferred_probe_work_func+0x11c/0x180 [ 31.084451] process_one_work+0x3ac/0x988 [ 31.084643] worker_thread+0x398/0x694 [ 31.084752] kthread+0x1bc/0x1c0 [ 31.084848] ret_from_fork+0x10/0x20 [ 31.084932] irq event stamp: 64549 [ 31.084970] hardirqs last enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90 [ 31.085157] ---truncated--- | ["https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076","https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38","https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11","https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b","https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557","https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de","https://git.kernel.org/stable/c/0ccac964520a6f19e355652c8ca38af2a7f27076","https://git.kernel.org/stable/c/244296cc3a155199a8b080d19e645d7d49081a38","https://git.kernel.org/stable/c/8bf574183282d219cfa991f7df37aad491d74c11","https://git.kernel.org/stable/c/8e3c94767cad5150198e4337c8b91f3bb068e14b","https://git.kernel.org/stable/c/c660be571609e03e7d5972343536a736fcb31557","https://git.kernel.org/stable/c/fcdd5bb4a8c81c64c1334d7e0aba41a8829a24de","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38591 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix deadlock on SRQ async events. xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock. | ["https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868","https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d","https://git.kernel.org/stable/c/605889754ee68aacf7c381938fcd5eb654e71822","https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9","https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0","https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37","https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c","https://git.kernel.org/stable/c/22c915af31bd84ffaa46145e317f53333f94a868","https://git.kernel.org/stable/c/4a3be1a0ffe04c085dd7f79be97c91b0c786df3d","https://git.kernel.org/stable/c/72dc542f0d8977e7d41d610db6bb65c47cad43e9","https://git.kernel.org/stable/c/756ddbe665ea7f9416951bd76731b174d136eea0","https://git.kernel.org/stable/c/b46494b6f9c19f141114a57729e198698f40af37","https://git.kernel.org/stable/c/d271e66abac5c7eb8de345b9b44d89f777437a4c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42090 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock. This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. | ["https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e","https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc","https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0","https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd","https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1","https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6","https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b","https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04","https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e","https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc","https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0","https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd","https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1","https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6","https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b","https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52912 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fixed bug on error when unloading amdgpu Fixed bug on error when unloading amdgpu. The error message is as follows: [ 377.706202] kernel BUG at drivers/gpu/drm/drm_buddy.c:278! [ 377.706215] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 377.706222] CPU: 4 PID: 8610 Comm: modprobe Tainted: G IOE 6.0.0-thomas #1 [ 377.706231] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 11/02/2021 [ 377.706238] RIP: 0010:drm_buddy_free_block+0x26/0x30 [drm_buddy] [ 377.706264] Code: 00 00 00 90 0f 1f 44 00 00 48 8b 0e 89 c8 25 00 0c 00 00 3d 00 04 00 00 75 10 48 8b 47 18 48 d3 e0 48 01 47 28 e9 fa fe ff ff <0f> 0b 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 54 55 48 89 f5 53 [ 377.706282] RSP: 0018:ffffad2dc4683cb8 EFLAGS: 00010287 [ 377.706289] RAX: 0000000000000000 RBX: ffff8b1743bd5138 RCX: 0000000000000000 [ 377.706297] RDX: ffff8b1743bd5160 RSI: ffff8b1743bd5c78 RDI: ffff8b16d1b25f70 [ 377.706304] RBP: ffff8b1743bd59e0 R08: 0000000000000001 R09: 0000000000000001 [ 377.706311] R10: ffff8b16c8572400 R11: ffffad2dc4683cf0 R12: ffff8b16d1b25f70 [ 377.706318] R13: ffff8b16d1b25fd0 R14: ffff8b1743bd59c0 R15: ffff8b16d1b25f70 [ 377.706325] FS: 00007fec56c72c40(0000) GS:ffff8b1836500000(0000) knlGS:0000000000000000 [ 377.706334] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 377.706340] CR2: 00007f9b88c1ba50 CR3: 0000000110450004 CR4: 00000000003706e0 [ 377.706347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 377.706354] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 377.706361] Call Trace: [ 377.706365] <TASK> [ 377.706369] drm_buddy_free_list+0x2a/0x60 [drm_buddy] [ 377.706376] amdgpu_vram_mgr_fini+0xea/0x180 [amdgpu] [ 377.706572] amdgpu_ttm_fini+0x12e/0x1a0 [amdgpu] [ 377.706650] amdgpu_bo_fini+0x22/0x90 [amdgpu] [ 377.706727] gmc_v11_0_sw_fini+0x26/0x30 [amdgpu] [ 377.706821] amdgpu_device_fini_sw+0xa1/0x3c0 [amdgpu] [ 377.706897] amdgpu_driver_release_kms+0x12/0x30 [amdgpu] [ 377.706975] drm_dev_release+0x20/0x40 [drm] [ 377.707006] release_nodes+0x35/0xb0 [ 377.707014] devres_release_all+0x8b/0xc0 [ 377.707020] device_unbind_cleanup+0xe/0x70 [ 377.707027] device_release_driver_internal+0xee/0x160 [ 377.707033] driver_detach+0x44/0x90 [ 377.707039] bus_remove_driver+0x55/0xe0 [ 377.707045] pci_unregister_driver+0x3b/0x90 [ 377.707052] amdgpu_exit+0x11/0x6c [amdgpu] [ 377.707194] __x64_sys_delete_module+0x142/0x2b0 [ 377.707201] ? fpregs_assert_state_consistent+0x22/0x50 [ 377.707208] ? exit_to_user_mode_prepare+0x3e/0x190 [ 377.707215] do_syscall_64+0x38/0x90 [ 377.707221] entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/9196eb7c52e55749a332974f0081f77d53d60199","https://git.kernel.org/stable/c/99f1a36c90a7524972be5a028424c57fa17753ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43886 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check in resource_log_pipe_topology_update [WHY] When switching from "Extend" to "Second Display Only" we sometimes call resource_get_otg_master_for_stream on a stream for the eDP, which is disconnected. This leads to a null pointer dereference. [HOW] Added a null check in dc_resource.c/resource_log_pipe_topology_update. | ["https://git.kernel.org/stable/c/899d92fd26fe780aad711322aa671f68058207a6","https://git.kernel.org/stable/c/c36e922a36bdf69765c340a0857ca74092003bee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null pointer deref in dcn20_resource.c Fixes a hang thats triggered when MPV is run on a DCN401 dGPU: mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all and then enabling fullscreen playback (double click on the video) The following calltrace will be seen: [ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 181.843997] #PF: supervisor instruction fetch in kernel mode [ 181.844003] #PF: error_code(0x0010) - not-present page [ 181.844009] PGD 0 P4D 0 [ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [ 181.844044] RIP: 0010:0x0 [ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [ 181.844141] Call Trace: [ 181.844146] <TASK> [ 181.844153] ? show_regs+0x6d/0x80 [ 181.844167] ? __die+0x24/0x80 [ 181.844179] ? page_fault_oops+0x99/0x1b0 [ 181.844192] ? do_user_addr_fault+0x31d/0x6b0 [ 181.844204] ? exc_page_fault+0x83/0x1b0 [ 181.844216] ? asm_exc_page_fault+0x27/0x30 [ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu] [ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu] | ["https://git.kernel.org/stable/c/974fccd61758599a9716c4b909d9226749efe37e","https://git.kernel.org/stable/c/ecbf60782662f0a388493685b85a645a0ba1613c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401 When users run the command: cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log The following NULL pointer dereference happens: [ +0.000003] BUG: kernel NULL pointer dereference, address: NULL [ +0.000005] #PF: supervisor instruction fetch in kernel mode [ +0.000002] #PF: error_code(0x0010) - not-present page [ +0.000002] PGD 0 P4D 0 [ +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI [ +0.000003] RIP: 0010:0x0 [ +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [...] [ +0.000002] PKRU: 55555554 [ +0.000002] Call Trace: [ +0.000002] <TASK> [ +0.000003] ? show_regs+0x65/0x70 [ +0.000006] ? __die+0x24/0x70 [ +0.000004] ? page_fault_oops+0x160/0x470 [ +0.000006] ? do_user_addr_fault+0x2b5/0x690 [ +0.000003] ? prb_read_valid+0x1c/0x30 [ +0.000005] ? exc_page_fault+0x8c/0x1a0 [ +0.000005] ? asm_exc_page_fault+0x27/0x30 [ +0.000012] dcn10_log_color_state+0xf9/0x510 [amdgpu] [ +0.000306] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000003] ? vsnprintf+0x2fb/0x600 [ +0.000009] dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu] [ +0.000218] ? __mod_memcg_lruvec_state+0xe8/0x170 [ +0.000008] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? debug_smp_processor_id+0x17/0x20 [ +0.000003] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? set_ptes.isra.0+0x2b/0x90 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? _raw_spin_unlock+0x19/0x40 [ +0.000004] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000002] ? do_anonymous_page+0x337/0x700 [ +0.000004] dtn_log_read+0x82/0x120 [amdgpu] [ +0.000207] full_proxy_read+0x66/0x90 [ +0.000007] vfs_read+0xb0/0x340 [ +0.000005] ? __count_memcg_events+0x79/0xe0 [ +0.000002] ? srso_alias_return_thunk+0x5/0xfbef5 [ +0.000003] ? count_memcg_events.constprop.0+0x1e/0x40 [ +0.000003] ? handle_mm_fault+0xb2/0x370 [ +0.000003] ksys_read+0x6b/0xf0 [ +0.000004] __x64_sys_read+0x19/0x20 [ +0.000003] do_syscall_64+0x60/0x130 [ +0.000004] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ +0.000003] RIP: 0033:0x7fdf32f147e2 [...] This error happens when the color log tries to read the gamut remap information from DCN401 which is not initialized in the dcn401_dpp_funcs which leads to a null pointer dereference. This commit addresses this issue by adding a proper guard to access the gamut_remap callback in case the specific ASIC did not implement this function. | ["https://git.kernel.org/stable/c/1e68b7ce6bc6073579fe8713ec6b85aa9cd2e351","https://git.kernel.org/stable/c/5af757124792817f8eb1bd0c80ad60fab519586b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52825 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix a race condition of vram buffer unref in svm code prange->svm_bo unref can happen in both mmu callback and a callback after migrate to system ram. Both are async call in different tasks. Sync svm_bo unref operation to avoid random "use-after-free". | ["https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e","https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74","https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34","https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf","https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659","https://git.kernel.org/stable/c/50f35a907c4f9ed431fd3dbb8b871ef1cbb0718e","https://git.kernel.org/stable/c/709c348261618da7ed89d6c303e2ceb9e453ba74","https://git.kernel.org/stable/c/7d43cdd22cd81a2b079e864c4321b9aba4c6af34","https://git.kernel.org/stable/c/c772eacbd6d0845fc922af8716bb9d29ae27b8cf","https://git.kernel.org/stable/c/fc0210720127cc6302e6d6f3de48f49c3fcf5659"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52919 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: fix possible NULL pointer dereference in send_acknowledge() Handle memory allocation failure from nci_skb_alloc() (calling alloc_skb()) to avoid possible NULL pointer dereference. | ["https://git.kernel.org/stable/c/2b2edf089df3a69f0072c6e71563394c5a94e62e","https://git.kernel.org/stable/c/5622592f8f74ae3e594379af02e64ea84772d0dd","https://git.kernel.org/stable/c/76050b0cc5a72e0c7493287b7e18e1cb9e3c4612","https://git.kernel.org/stable/c/7937609cd387246aed994e81aa4fa951358fba41","https://git.kernel.org/stable/c/bb6cacc439ddd2cd51227ab193f4f91cfc7f014f","https://git.kernel.org/stable/c/c95fa5b20fe03609e0894656fa43c18045b5097e","https://git.kernel.org/stable/c/d7dbdbe3800a908eecd4975c31be47dd45e2104a","https://git.kernel.org/stable/c/ffdc881f68073ff86bf21afb9bb954812e8278be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47663 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0e727707a239d5c519fc9abc2f0fd913516a7e47","https://git.kernel.org/stable/c/3ba9abfcaa9e16bb91ed7e0e2b42e94a157a953e","https://git.kernel.org/stable/c/41cc91e3138fe52f8da92a81bebcd0e6cf488c53","https://git.kernel.org/stable/c/5edc3a45ef428501000a7b23d0e1777a548907f6","https://git.kernel.org/stable/c/8961b245e8f92bccbaacfbbdf69eba60e3e7c227","https://git.kernel.org/stable/c/b48aa991758999d4e8f9296c5bbe388f293ef465","https://git.kernel.org/stable/c/d8b09a5edc4a634373158c1a405491de3c52e58a","https://git.kernel.org/stable/c/dc12e49f970b08d8b007b8981b97e2eb93c0e89d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47669 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix state management in error path of log writing function After commit a694291a6211 ("nilfs2: separate wait function from nilfs_segctor_write") was applied, the log writing function nilfs_segctor_do_construct() was able to issue I/O requests continuously even if user data blocks were split into multiple logs across segments, but two potential flaws were introduced in its error handling. First, if nilfs_segctor_begin_construction() fails while creating the second or subsequent logs, the log writing function returns without calling nilfs_segctor_abort_construction(), so the writeback flag set on pages/folios will remain uncleared. This causes page cache operations to hang waiting for the writeback flag. For example, truncate_inode_pages_final(), which is called via nilfs_evict_inode() when an inode is evicted from memory, will hang. Second, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. As a result, if the next log write involves checkpoint creation, that's fine, but if a partial log write is performed that does not, inodes with NILFS_I_COLLECTED set are erroneously removed from the "sc_dirty_files" list, and their data and b-tree blocks may not be written to the device, corrupting the block mapping. Fix these issues by uniformly calling nilfs_segctor_abort_construction() on failure of each step in the loop in nilfs_segctor_do_construct(), having it clean up logs and segment usages according to progress, and correcting the conditions for calling nilfs_redirty_inodes() to ensure that the NILFS_I_COLLECTED flag is cleared. | ["https://git.kernel.org/stable/c/036441e8438b29111fa75008f0ce305fb4e83c0a","https://git.kernel.org/stable/c/0a1a961bde4351dc047ffdeb2f1311ca16a700cc","https://git.kernel.org/stable/c/30562eff4a6dd35c4b5be9699ef61ad9f5f20a06","https://git.kernel.org/stable/c/3e349d7191f0688fc9808ef24fd4e4b4ef5ca876","https://git.kernel.org/stable/c/40a2757de2c376ef8a08d9ee9c81e77f3c750adf","https://git.kernel.org/stable/c/6576dd6695f2afca3f4954029ac4a64f82ba60ab","https://git.kernel.org/stable/c/74866c16ea2183f52925fa5d76061a1fe7f7737b","https://git.kernel.org/stable/c/efdde00d4a1ef10bb71e09ebc67823a3d3ad725b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47672 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't wait for tx queues if firmware is dead There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. [edit commit message] | ["https://git.kernel.org/stable/c/16c1e5d5228f26f120e12e6ca55c59c3a5e6dece","https://git.kernel.org/stable/c/1afed66cb271b3e65fe9df1c9fba2bf4b1f55669","https://git.kernel.org/stable/c/1b0cd832c9607f41f84053b818e0b7908510a3b9","https://git.kernel.org/stable/c/3a84454f5204718ca5b4ad2c1f0bf2031e2403d1","https://git.kernel.org/stable/c/4d0a900ec470d392476c428875dbf053f8a0ae5e","https://git.kernel.org/stable/c/7188b7a72320367554b76d8f298417b070b05dd3","https://git.kernel.org/stable/c/ad2fcc2daa203a6ad491f00e9ae3b7867e8fe0f3","https://git.kernel.org/stable/c/de46b1d24f5f752b3bd8b46673c2ea4239661244"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47690 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs. | ["https://git.kernel.org/stable/c/884ee6dc85b959bc152f15bca80c30f06069e6c4","https://git.kernel.org/stable/c/8be95cd607478d85fa4626e86f811e785905bcbf","https://git.kernel.org/stable/c/bcefd0b0611f35b560d0a7281d87529fbe7a1e32","https://git.kernel.org/stable/c/e8d64f598eeb079c42a52deaa3a91312c736a49d","https://git.kernel.org/stable/c/f4746f2d79507f65cfbde11d3c39ee8338aa50af","https://git.kernel.org/stable/c/f9ce2f550d53d044ecfb5ce996406cf42cd6b84d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47707 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated--- | ["https://git.kernel.org/stable/c/04ccecfa959d3b9ae7348780d8e379c6486176ac","https://git.kernel.org/stable/c/08409e401622e2896b4313be9f781bde8a2a6a53","https://git.kernel.org/stable/c/0ceb2f2b5c813f932d6e60d3feec5e7e713da783","https://git.kernel.org/stable/c/8a8b83016f06805775db099c8377024b6fa5b975","https://git.kernel.org/stable/c/9a0ddc73be37d19dff1ba08290af34e707d18e50","https://git.kernel.org/stable/c/a61a174280dad99f25a7dee920310885daf2552b","https://git.kernel.org/stable/c/e43dd28405e6b9935279996725ee11e6306547a5","https://git.kernel.org/stable/c/f2bd9635543ca41533b870f420872819f8331823"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47710 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed. | ["https://git.kernel.org/stable/c/04f62c012e0e4683e572b30baf6004ca0a3f6772","https://git.kernel.org/stable/c/1a11a1a53255ddab8a903cdae01b9d3eb2c1a47b","https://git.kernel.org/stable/c/80bd490ac0a3b662a489e17d8eedeb1e905a3d40","https://git.kernel.org/stable/c/984648aac87a6a1c8fd61663bec3f7b61eafad5e","https://git.kernel.org/stable/c/ae8c1b3e7353ad240b829eabac7ba2584b2c6bdc","https://git.kernel.org/stable/c/b1339be951ad31947ae19bc25cb08769bf255100","https://git.kernel.org/stable/c/bc05f6855642cff3c0eeb63060b35d8c4f8a851d","https://git.kernel.org/stable/c/cd10abf41bae55c9d2b93f34a516dbf52626bcb7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47720 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 } | ["https://git.kernel.org/stable/c/08ae395ea22fb3d9b318c8bde28c0dfd2f5fa4d2","https://git.kernel.org/stable/c/44948d3cb943602ba4a0b5ed3c91ae0525838fb1","https://git.kernel.org/stable/c/64886a4e6f1dce843c0889505cf0673b5211e16a","https://git.kernel.org/stable/c/72ee32d0907364104fbcf4f68dd5ae63cd8eae9e","https://git.kernel.org/stable/c/84edd5a3f5fa6aafa4afcaf9f101f46426c620c9","https://git.kernel.org/stable/c/ddf9ff244d704e1903533f7be377615ed34b83e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47739 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow. | ["https://git.kernel.org/stable/c/1b8cf11b3ca593a8802a51802cd0c28c38501428","https://git.kernel.org/stable/c/1bd712de96ad7167fe0d608e706cd60587579f16","https://git.kernel.org/stable/c/46c4079460f4dcaf445860679558eedef4e1bc91","https://git.kernel.org/stable/c/72164d5b648951684b1a593996b37a6083c61d7d","https://git.kernel.org/stable/c/9a22b2812393d93d84358a760c347c21939029a6","https://git.kernel.org/stable/c/9e279e6c1f012b82628b89e1b9c65dbefa8ca25a","https://git.kernel.org/stable/c/ab205e1c3846326f162180e56825b4ba38ce9c30"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49851 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure. | ["https://git.kernel.org/stable/c/2c9b228938e9266a1065a3f4fe5c99b7235dc439","https://git.kernel.org/stable/c/3f9f72d843c92fb6f4ff7460d774413cde7f254c","https://git.kernel.org/stable/c/82478cb8a23bd4f97935bbe60d64528c6d9918b4","https://git.kernel.org/stable/c/87e8134c18977b566f4ec248c8a147244da69402","https://git.kernel.org/stable/c/adf4ce162561222338cf2c9a2caa294527f7f721","https://git.kernel.org/stable/c/c84ceb546f30432fccea4891163f7050f5bee5dd","https://git.kernel.org/stable/c/e3aaebcbb7c6b403416f442d1de70d437ce313a7","https://git.kernel.org/stable/c/ebc4e1f4492d114f9693950621b3ea42b2f82bec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49871 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early. | ["https://git.kernel.org/stable/c/122b160561f6429701a0559a0f39b0ae309488c6","https://git.kernel.org/stable/c/34e304cc53ae5d3c8e3f08b41dd11e0d4f3e01ed","https://git.kernel.org/stable/c/4449fedb8a710043fc0925409eba844c192d4337","https://git.kernel.org/stable/c/7c3f04223aaf82489472d614c6decee5a1ce8d7f","https://git.kernel.org/stable/c/9a38791ee79bd17d225c15a6d1479448be127a59","https://git.kernel.org/stable/c/fb5cc65f973661241e4a2b7390b429aa7b330c69"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49879 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue. | ["https://git.kernel.org/stable/c/0d71916694aceb207fefecf62dfa811ec1108bbd","https://git.kernel.org/stable/c/2bda89735199683b03f55b807bd1e31a3857520b","https://git.kernel.org/stable/c/334de68eda2b99892ba869c15cb59bc956fd9f42","https://git.kernel.org/stable/c/b57b53e8ffcdfda87d954fc4187426a54fe75a3d","https://git.kernel.org/stable/c/c17a4f52fa3c3dac2dd6a3c38f2de7342d97d74c","https://git.kernel.org/stable/c/e60b0d3b5aa2e8d934deca9e11215af84e632bc9","https://git.kernel.org/stable/c/e794b7b9b92977365c693760a259f8eef940c536","https://git.kernel.org/stable/c/f37a1d9e5e22d5489309c3cd2db476dcdcc6530c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49881 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: <TASK> ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath. | ["https://git.kernel.org/stable/c/11b230100d6801c014fab2afabc8bdea304c1b96","https://git.kernel.org/stable/c/5b4b2dcace35f618fe361a87bae6f0d13af31bc1","https://git.kernel.org/stable/c/6766937d0327000ac1b87c97bbecdd28b0dd6599","https://git.kernel.org/stable/c/6801ed1298204d16a38571091e31178bfdc3c679","https://git.kernel.org/stable/c/a9fcb1717d75061d3653ed69365c8d45331815cd","https://git.kernel.org/stable/c/b63481b3a388ee2df9e295f97273226140422a42","https://git.kernel.org/stable/c/ec0c0beb9b777cdd1edd7df9b36e0f3e67e2bdff","https://git.kernel.org/stable/c/f55ecc58d07a6c1f6d6d5b5af125c25f8da0bda2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49946 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [<ffff80008b42e30c>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [<ffff80008b42e30c>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [<ffff80008b42e13c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [<ffff80008b42e13c>] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [<ffff8000801f8e88>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [<ffff8000801f8e88>] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [<ffff8000801fbdf8>] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); <Interrupt> lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated--- | ["https://git.kernel.org/stable/c/176dd41e8c2bd997ed3d66568a3362e69ecce99b","https://git.kernel.org/stable/c/635deca1800a68624f185dc1e04a8495b48cf185","https://git.kernel.org/stable/c/aec7291003df78cb71fd461d7b672912bde55807","https://git.kernel.org/stable/c/c837f8583535f094a39386308c2ccfd92c8596cd","https://git.kernel.org/stable/c/efe9cc0f7c0279216a5522271ec675b8288602e4","https://git.kernel.org/stable/c/f9620e2a665aa642625bd2501282bbddff556bd7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49954 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn(). | ["https://git.kernel.org/stable/c/85a104aaef1f56623acc10ba4c42d5f046ba65b7","https://git.kernel.org/stable/c/b83bef74c121a3311240fc4002d23486b85355e4","https://git.kernel.org/stable/c/bc9356513d56b688775497b7ac6f2b967f46a80c","https://git.kernel.org/stable/c/e67534bd31d79952b50e791e92adf0b3e6c13b8c","https://git.kernel.org/stable/c/ea2cdf4da093d0482f0ef36ba971e2e0c7673425","https://git.kernel.org/stable/c/fe513c2ef0a172a58f158e2e70465c4317f0a9a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49973 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. | ["https://git.kernel.org/stable/c/1c723d785adb711496bc64c24240f952f4faaabf","https://git.kernel.org/stable/c/21950321ad33d7613b1453f4c503d7b1871deb61","https://git.kernel.org/stable/c/585c048d15ed559f20cb94c8fa2f30077efa4fbc","https://git.kernel.org/stable/c/64648ae8c97ec5a3165021627f5a1658ebe081ca","https://git.kernel.org/stable/c/92bc8647b4d65f4d4bf8afdb206321c1bc55a486","https://git.kernel.org/stable/c/991e8b0bab669b7d06927c3e442b3352532e8581","https://git.kernel.org/stable/c/ced8e8b8f40accfcce4a2bbd8b150aa76d5eff9a","https://git.kernel.org/stable/c/fe44b3bfbf0c74df5712f44458689d0eccccf47d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50000 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0168ab6fbd9e50d20b97486168b604b2ab28a2ca","https://git.kernel.org/stable/c/1bcc86cc721bea68980098f51f102aa2c2b9d932","https://git.kernel.org/stable/c/4655456a64a0f936098c8432bac64e7176bd2aff","https://git.kernel.org/stable/c/4d80dde26d7bab1320210279483ac854dcb274b2","https://git.kernel.org/stable/c/b48ee5bb25c02ca2b81e0d16bf8af17ab6ed3f8b","https://git.kernel.org/stable/c/f25389e779500cf4a59ef9804534237841bce536"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50002 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer. | ["https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd","https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a","https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c","https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4","https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c","https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50013 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak. | ["https://git.kernel.org/stable/c/4e1813e52f86eb8db0c6c9570251f2fcbc571f5d","https://git.kernel.org/stable/c/89081e8407e637463db5880d168e3652fb9f4330","https://git.kernel.org/stable/c/bf0b3b35259475d1fe377bcaa565488e26684f7a","https://git.kernel.org/stable/c/d2b537b3e533f28e0d97293fe9293161fe8cd137","https://git.kernel.org/stable/c/dca359db1eb37f334267ebd7e3cab9a66d191d5b","https://git.kernel.org/stable/c/ddf704c2ce3b73f38d2dd8cf1bb0f7ec038bdf63","https://git.kernel.org/stable/c/f692160d3e1e5450605071b8df8f7d08d9b09a83"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50015 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected. | ["https://git.kernel.org/stable/c/5efccdee4a7d507a483f20f880b809cc4eaef14d","https://git.kernel.org/stable/c/8c30a9a8610c314554997f86370140746aa35661","https://git.kernel.org/stable/c/a9f331f51515bdb3ebc8d0963131af367ef468f6","https://git.kernel.org/stable/c/abfaa876b948baaea4d14f21a1963789845c8b4c","https://git.kernel.org/stable/c/dda898d7ffe85931f9cca6d702a51f33717c501e","https://git.kernel.org/stable/c/ec0dd451e236c46e4858d53e9e82bae7797a7af5","https://git.kernel.org/stable/c/f8a7c342326f6ad1dfdb30a18dd013c70f5e9669"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50024 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list. | ["https://git.kernel.org/stable/c/1cdec792b2450105b1314c5123a9a0452cb2c2f0","https://git.kernel.org/stable/c/1dae9f1187189bc09ff6d25ca97ead711f7e26f9","https://git.kernel.org/stable/c/3be342e0332a7c83eb26fbb22bf156fdca467a5d","https://git.kernel.org/stable/c/464801a0f6ccb52b21faa33bac6014fd74cc5e10","https://git.kernel.org/stable/c/49f9b726bf2bf3dd2caf0d27cadf4bc1ccf7a7dd","https://git.kernel.org/stable/c/5f03a7f601f33cda1f710611625235dc86fd8a9e","https://git.kernel.org/stable/c/68ad5da6ca630a276f0a5c924179e57724d00013","https://git.kernel.org/stable/c/8e0766fcf37ad8eed289dd3853628dd9b01b58b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50039 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ... Code starting with the faulting instruction =========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] <TASK> [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated--- | ["https://git.kernel.org/stable/c/1edf039ee01788ffc25625fe58a903ae2efa213e","https://git.kernel.org/stable/c/2acbb9539bc2284e30d2aeb789c3d96287014264","https://git.kernel.org/stable/c/3cb7cf1540ddff5473d6baeb530228d19bc97b8a","https://git.kernel.org/stable/c/3dc6ee96473cc2962c6db4297d4631f261be150f","https://git.kernel.org/stable/c/76feedc74b90270390fbfdf74a2e944e96872363","https://git.kernel.org/stable/c/8fb6503592d39065316f45d267c5527b4e7cd995","https://git.kernel.org/stable/c/adbc3eef43fc94c7c8436da832691ae02333a972"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50045 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated--- | ["https://git.kernel.org/stable/c/3453f5839420bfbb85c86c61e49f49ffd0f041c4","https://git.kernel.org/stable/c/75dfcb758015c97e1accd6340691fca67d363bed","https://git.kernel.org/stable/c/78ed917133b118661e1fe62d4a85d5d428ee9568","https://git.kernel.org/stable/c/915717e0bb9837cc5c101bc545af487bd787239e","https://git.kernel.org/stable/c/95c0cff5a1a5d28bf623b92eb5d1a8f56ed30803","https://git.kernel.org/stable/c/cce8419b8168f6e7eb637103a47f916f3de8bc81","https://git.kernel.org/stable/c/f07131239a76cc10d5e82c19d91f53cb55727297","https://git.kernel.org/stable/c/f9ff7665cd128012868098bbd07e28993e314fdb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50046 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated--- | ["https://git.kernel.org/stable/c/584c019baedddec3fd634053e8fb2d8836108d38","https://git.kernel.org/stable/c/632344b9efa064ca737bfcdaaaced59fd5f18ae9","https://git.kernel.org/stable/c/a848c29e3486189aaabd5663bc11aea50c5bd144","https://git.kernel.org/stable/c/ef9189bb15dcbe7ed3f3515aaa6fc8bf7483960d","https://git.kernel.org/stable/c/f892165c564e3aab272948dbb556cc20e290c55a","https://git.kernel.org/stable/c/fca41e5fa4914d12b2136c25f9dad69520b52683"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50103 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe() A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() could possibly return NULL pointer. NULL Pointer Dereference may be triggerred without addtional check. Add a NULL check for the returned pointer. | ["https://git.kernel.org/stable/c/03c9c2c2d2d0fe203dfe8f56bedbcf04e303d7c4","https://git.kernel.org/stable/c/1e235d02d803660777ec911a2c467ae41f8539f5","https://git.kernel.org/stable/c/49da1463c9e3d2082276c3e0e2a8b65a88711cd2","https://git.kernel.org/stable/c/73cc3f905ca9aa95694eea3dfa1acadc90686368","https://git.kernel.org/stable/c/a8e691fe1894c8bdf815a6171ee22ae7da8b18aa","https://git.kernel.org/stable/c/e19bf49e903337641fc230d430d49813e3199902"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50116 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of buffer delay flag Syzbot reported that after nilfs2 reads a corrupted file system image and degrades to read-only, the BUG_ON check for the buffer delay flag in submit_bh_wbc() may fail, causing a kernel bug. This is because the buffer delay flag is not cleared when clearing the buffer state flags to discard a page/folio or a buffer head. So, fix this. This became necessary when the use of nilfs2's own page clear routine was expanded. This state inconsistency does not occur if the buffer is written normally by log writing. | ["https://git.kernel.org/stable/c/033bc52f35868c2493a2d95c56ece7fc155d7cb3","https://git.kernel.org/stable/c/27524f65621f490184f2ace44cd8e5f3685af4a3","https://git.kernel.org/stable/c/412a30b1b28d6073ba29c46a2b0f324c5936293f","https://git.kernel.org/stable/c/6ed469df0bfbef3e4b44fca954a781919db9f7ab","https://git.kernel.org/stable/c/743c78d455e784097011ea958b27396001181567","https://git.kernel.org/stable/c/822203f6355f4b322d21e7115419f6b98284be25","https://git.kernel.org/stable/c/9f2ab98371c2f2488bf3bf3f9b2a73510545e9c1","https://git.kernel.org/stable/c/c6f58ff2d4c552927fe9a187774e668ebba6c7aa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50117 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd: Guard against bad data for ATIF ACPI method If a BIOS provides bad data in response to an ATIF method call this causes a NULL pointer dereference in the caller. ``` ? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1)) ? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434) ? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2)) ? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1)) ? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642) ? exc_page_fault (arch/x86/mm/fault.c:1542) ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu ? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu ``` It has been encountered on at least one system, so guard for it. (cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee) | ["https://git.kernel.org/stable/c/1d7175f9c57b1abf9ecfbdfd53ea760761f52ffe","https://git.kernel.org/stable/c/234682910971732cd4da96fd95946e296e486b38","https://git.kernel.org/stable/c/43b4fa6e0e238c6e2662f4fb61d9f51c2785fb1d","https://git.kernel.org/stable/c/58556dcbd5606a5daccaee73b2130bc16b48e025","https://git.kernel.org/stable/c/6032287747f874b52dc8b9d7490e2799736e035f","https://git.kernel.org/stable/c/975ede2a7bec52b5da1428829b3439667c8a234b","https://git.kernel.org/stable/c/bf58f03931fdcf7b3c45cb76ac13244477a60f44","https://git.kernel.org/stable/c/cd67af3c1762de4c2483ae4dbdd98f9ea8fa56e3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21917 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: renesas_usbhs: Flush the notify_hotplug_work When performing continuous unbind/bind operations on the USB drivers available on the Renesas RZ/G2L SoC, a kernel crash with the message "Unable to handle kernel NULL pointer dereference at virtual address" may occur. This issue points to the usbhsc_notify_hotplug() function. Flush the delayed work to avoid its execution when driver resources are unavailable. | ["https://git.kernel.org/stable/c/3248c1f833f924246cb98ce7da4569133c1b2292","https://git.kernel.org/stable/c/394965f90454d6f00fe11879142b720c6c1a872e","https://git.kernel.org/stable/c/4ca078084cdd5f32d533311d6a0b63a60dcadd41","https://git.kernel.org/stable/c/4cd847a7b630a85493d0294ad9542c21aafaa246","https://git.kernel.org/stable/c/552ca6b87e3778f3dd5b87842f95138162e16c82","https://git.kernel.org/stable/c/830818c8e70c0364e377f0c243b28061ef7967eb","https://git.kernel.org/stable/c/d50f5c0cd949593eb9a3d822b34d7b50046a06b7","https://git.kernel.org/stable/c/e5aac1c9b2974636db7ce796ffa6de88fa08335e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48918 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iwlwifi: mvm: check debugfs_dir ptr before use When "debugfs=off" is used on the kernel command line, iwiwifi's mvm module uses an invalid/unchecked debugfs_dir pointer and causes a BUG: BUG: kernel NULL pointer dereference, address: 000000000000004f #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7 Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021 RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm] Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73 RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246 RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328 RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620 R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000 R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320 FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: <TASK> ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm] iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm] iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm] _iwl_op_mode_start+0x6f/0xd0 [iwlwifi] iwl_opmode_register+0x6a/0xe0 [iwlwifi] ? 0xffffffffa0231000 iwl_mvm_init+0x35/0x1000 [iwlmvm] ? 0xffffffffa0231000 do_one_initcall+0x5a/0x1b0 ? kmem_cache_alloc+0x1e5/0x2f0 ? do_init_module+0x1e/0x220 do_init_module+0x48/0x220 load_module+0x2602/0x2bc0 ? __kernel_read+0x145/0x2e0 ? kernel_read_file+0x229/0x290 __do_sys_finit_module+0xc5/0x130 ? __do_sys_finit_module+0xc5/0x130 __x64_sys_finit_module+0x13/0x20 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f64dda564dd Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48 RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001 RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002 R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2 R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018 </TASK> Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev CR2: 000000000000004f ---[ end trace 0000000000000000 ]--- Check the debugfs_dir pointer for an error before using it. [change to make both conditional] | ["https://git.kernel.org/stable/c/5a6248c0a22352f09ea041665d3bd3e18f6f872c","https://git.kernel.org/stable/c/7de1ed755e1ace30d97a724bad32452ed86b653b","https://git.kernel.org/stable/c/fe51975ff13831e794e1bcd0039b305dcad3d7ba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48929 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix crash due to out of bounds access into reg2btf_ids. When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier reg type to the appropriate btf_vmlinux BTF ID, however commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL") moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after the base register types, and defined other variants using type flag composition. However, now, the direct usage of reg->type to index into reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to out of bounds access and kernel crash on dereference of bad pointer. | ["https://git.kernel.org/stable/c/45ce4b4f9009102cd9f581196d480a59208690c1","https://git.kernel.org/stable/c/8c39925e98d498b9531343066ef82ae39e41adae","https://git.kernel.org/stable/c/f0ce1bc9e0235dd7412240be493d7ea65ed9eadc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47728 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again. | ["https://git.kernel.org/stable/c/4b3786a6c5397dc220b1483d8e2f4867743e966f","https://git.kernel.org/stable/c/594a9f5a8d2de2573a856e506f77ba7dd2cefc6a","https://git.kernel.org/stable/c/599d15b6d03356a97bff7a76155c5604c42a2962","https://git.kernel.org/stable/c/8397bf78988f3ae9dbebb0200189a62a57264980","https://git.kernel.org/stable/c/a634fa8e480ac2423f86311a602f6295df2c8ed0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49978 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. | ["https://git.kernel.org/stable/c/080e6c9a3908de193a48f646c5ce1bfb15676ffc","https://git.kernel.org/stable/c/33e28acf42ee863f332a958bfc2f1a284a3659df","https://git.kernel.org/stable/c/3cd00d2e3655fad3bda96dc1ebf17b6495f86fea","https://git.kernel.org/stable/c/a1e40ac5b5e9077fe1f7ae0eb88034db0f9ae1ab","https://git.kernel.org/stable/c/af3122f5fdc0d00581d6e598a668df6bf54c9daa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50019 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread. | ["https://git.kernel.org/stable/c/19a5029981c87c2ad0845e713837faa88f5d8e2b","https://git.kernel.org/stable/c/214e01ad4ed7158cab66498810094fac5d09b218","https://git.kernel.org/stable/c/40a6e660d2a3a7a5cb99f0b8ff4fb41bad039f68","https://git.kernel.org/stable/c/8608196a155cb6cfae04d96b10a2652d0327e33f","https://git.kernel.org/stable/c/cda5423c1a1c906062ef235c940f249b97d9d135"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50031 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. | ["https://git.kernel.org/stable/c/07c51108d9e278831c16191d1223ee49986e7890","https://git.kernel.org/stable/c/0c9e9a3a4873705740b19300cadc6599170646ef","https://git.kernel.org/stable/c/24ab54a066d2ef671b03eb909ca2114c0c9ac1e7","https://git.kernel.org/stable/c/333767cbce6ac20ec794c76eec82ed0ef55022db","https://git.kernel.org/stable/c/7d1fd3638ee3a9f9bca4785fffb638ca19120718"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50038 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git. | ["https://git.kernel.org/stable/c/0bfcb7b71e735560077a42847f69597ec7dcc326","https://git.kernel.org/stable/c/4cdc55ec6222bb195995cc58f7cb46e4d8907056","https://git.kernel.org/stable/c/85ff9a0f793ca52c527e75cd40a69c948627ebde","https://git.kernel.org/stable/c/8f482bb7e27b37f1f734bb9a8eeb28b23d59d189","https://git.kernel.org/stable/c/997f67d813ce0cf5eb3cdb8f124da68141e91b6c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: Check for port partner validity before consuming it typec_register_partner() does not guarantee partner registration to always succeed. In the event of failure, port->partner is set to the error value or NULL. Given that port->partner validity is not checked, this results in the following crash: Unable to handle kernel NULL pointer dereference at virtual address xx pc : run_state_machine+0x1bc8/0x1c08 lr : run_state_machine+0x1b90/0x1c08 .. Call trace: run_state_machine+0x1bc8/0x1c08 tcpm_state_machine_work+0x94/0xe4 kthread_worker_fn+0x118/0x328 kthread+0x1d0/0x23c ret_from_fork+0x10/0x20 To prevent the crash, check for port->partner validity before derefencing it in all the call sites. | ["https://git.kernel.org/stable/c/2a07e6f0ad8a6e504a3912cfe8dc859b7d0740a5","https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637","https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd","https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57","https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77","https://git.kernel.org/stable/c/789326cafbd1f67f424436b6bc8bdb887a364637","https://git.kernel.org/stable/c/ae11f04b452b5205536e1c02d31f8045eba249dd","https://git.kernel.org/stable/c/d56d2ca03cc22123fd7626967d096d8661324e57","https://git.kernel.org/stable/c/fc2b655cb6dd2b381f1f284989721002e39b6b77"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50028 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure. | ["https://git.kernel.org/stable/c/a42a5839f400e929c489bb1b58f54596c4535167","https://git.kernel.org/stable/c/c95538b286efc6109c987e97a051bc7844ede802"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56716 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netdevsim: prevent bad user input in nsim_dev_health_break_write() If either a zero count or a large one is provided, kernel can crash. | ["https://git.kernel.org/stable/c/470c5ecbac2f19b1cdee2a6ce8d5650c3295c94b","https://git.kernel.org/stable/c/81bdfcd6e6a998e219c9dd49ec7291c2e0594bbc","https://git.kernel.org/stable/c/8e9ef6bdf71bf25f4735e0230ce1919de8985835","https://git.kernel.org/stable/c/b3a6daaf7cfb2de37b89fd7a5a2ad4ea9aa3e181","https://git.kernel.org/stable/c/d10321be26ff9e9e912697e9e8448099654ff561","https://git.kernel.org/stable/c/ee76746387f6233bdfa93d7406990f923641568f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47705 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls. | ["https://git.kernel.org/stable/c/26e197b7f9240a4ac301dd0ad520c0c697c2ea7d","https://git.kernel.org/stable/c/4bc4272e2506941c3f3d4fb8b0c659ee814dcf6f","https://git.kernel.org/stable/c/64cf2a39202ca2d9df5ee70eb310b6141ce2b8ed","https://git.kernel.org/stable/c/652039ba477c9a4ab43740cf2cb0d068d53508c2","https://git.kernel.org/stable/c/80f5bfbb80ea1615290dbc24f49d3d8c86db58fe","https://git.kernel.org/stable/c/afe53ea9b378c376101d99d216f13b6256f75189","https://git.kernel.org/stable/c/cc4d21d9492db4e534d3e01253cf885c90dd2a8b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44954 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: line6: Fix racy access to midibuf There can be concurrent accesses to line6 midibuf from both the URB completion callback and the rawmidi API access. This could be a cause of KMSAN warning triggered by syzkaller below (so put as reported-by here). This patch protects the midibuf call of the former code path with a spinlock for avoiding the possible races. | ["https://git.kernel.org/stable/c/15b7a03205b31bc5623378c190d22b7ff60026f1","https://git.kernel.org/stable/c/40f3d5cb0e0cbf7fa697913a27d5d361373bdcf5","https://git.kernel.org/stable/c/51d87f11dd199bbc6a85982b088ff27bde53b48a","https://git.kernel.org/stable/c/535df7f896a568a8a1564114eaea49d002cb1747","https://git.kernel.org/stable/c/643293b68fbb6c03f5e907736498da17d43f0d81","https://git.kernel.org/stable/c/a54da4b787dcac60b598da69c9c0072812b8282d","https://git.kernel.org/stable/c/c80f454a805443c274394b1db0d1ebf477abd94e","https://git.kernel.org/stable/c/e7e7d2b180d8f297cea6db43ea72402fd33e1a29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26747 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations. | ["https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa","https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db","https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e","https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734","https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1","https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913","https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa","https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db","https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e","https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734","https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1","https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39197 | High | fixed |
|
An out-of-bounds read vulnerability was found in Netfilter Connection Tracking (conntrack) in the Linux kernel. This flaw allows a remote user to disclose sensitive information via the DCCP protocol. | ["https://access.redhat.com/security/cve/CVE-2023-39197","https://bugzilla.redhat.com/show_bug.cgi?id=2218342","https://access.redhat.com/security/cve/CVE-2023-39197","https://bugzilla.redhat.com/show_bug.cgi?id=2218342"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56704 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: 9p/xen: fix release of IRQ Kernel logs indicate an IRQ was double-freed. Pass correct device ID during IRQ release. [Dominique: remove confusing variable reset to 0] | ["https://git.kernel.org/stable/c/2bb3ee1bf237557daea1d58007d2e1d4a6502ccf","https://git.kernel.org/stable/c/4950408793b118cb8075bcee1f033b543fb719fa","https://git.kernel.org/stable/c/530bc9f03a102fac95b07cda513bfc16ff69e0ee","https://git.kernel.org/stable/c/692eb06703afc3e24d889d77e94a0e20229f6a4a","https://git.kernel.org/stable/c/7f5a2ed5c1810661e6b03f5a4ebf17682cdea850","https://git.kernel.org/stable/c/b9e26059664bd9ebc64a0e8f5216266fc9f84265","https://git.kernel.org/stable/c/d74b4b297097bd361b8a9abfde9b521ff464ea9c","https://git.kernel.org/stable/c/d888f5f5d76b2722c267e6bdf51d445d60647b7b","https://git.kernel.org/stable/c/e43c608f40c065b30964f0a806348062991b802d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52973 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF After a call to console_unlock() in vcs_read() the vc_data struct can be freed by vc_deallocate(). Because of that, the struct vc_data pointer load must be done at the top of while loop in vcs_read() to avoid a UAF when vcs_size() is called. Syzkaller reported a UAF in vcs_size(). BUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215) Read of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537 CPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1 Hardware name: Red Hat KVM, BIOS 1.15.0-2.module Call Trace: <TASK> __asan_report_load4_noabort (mm/kasan/report_generic.c:350) vcs_size (drivers/tty/vt/vc_screen.c:215) vcs_read (drivers/tty/vt/vc_screen.c:415) vfs_read (fs/read_write.c:468 fs/read_write.c:450) ... </TASK> Allocated by task 1191: ... kmalloc_trace (mm/slab_common.c:1069) vc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720 drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108) con_install (drivers/tty/vt/vt.c:3383) tty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413 drivers/tty/tty_io.c:1390) tty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126) chrdev_open (fs/char_dev.c:415) do_dentry_open (fs/open.c:883) vfs_open (fs/open.c:1014) ... Freed by task 1548: ... kfree (mm/slab_common.c:1021) vc_port_destruct (drivers/tty/vt/vt.c:1094) tty_port_destructor (drivers/tty/tty_port.c:296) tty_port_put (drivers/tty/tty_port.c:312) vt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2)) vt_ioctl (drivers/tty/vt/vt_ioctl.c:903) tty_ioctl (drivers/tty/tty_io.c:2776) ... The buggy address belongs to the object at ffff888113747800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 424 bytes inside of 1024-byte region [ffff888113747800, ffff888113747c00) The buggy address belongs to the physical page: page:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x113740 head:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0 anon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff) raw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint | ["https://git.kernel.org/stable/c/226fae124b2dac217ea5436060d623ff3385bc34","https://git.kernel.org/stable/c/55515d7d8743b71b80bfe68e89eb9d92630626ab","https://git.kernel.org/stable/c/6332f52f44b9776568bf3c0b714ddfb0bb175e78","https://git.kernel.org/stable/c/8506f16aae9daf354e3732bcfd447e2a97f023df","https://git.kernel.org/stable/c/af79ea9a2443016f64d8fd8d72020cc874f0e066","https://git.kernel.org/stable/c/d0332cbf53dad06a22189cc341391237f4ea6d9f","https://git.kernel.org/stable/c/fc9e27f3ba083534b8bbf72ab0f5c810ffdc7d18"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52974 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress If during iscsi_sw_tcp_session_create() iscsi_tcp_r2tpool_alloc() fails, userspace could be accessing the host's ipaddress attr. If we then free the session via iscsi_session_teardown() while userspace is still accessing the session we will hit a use after free bug. Set the tcp_sw_host->session after we have completed session creation and can no longer fail. | ["https://git.kernel.org/stable/c/0aaabdb900c7415caa2006ef580322f7eac5f6b6","https://git.kernel.org/stable/c/496af9d3682ed4c28fb734342a09e6cc0c056ea4","https://git.kernel.org/stable/c/61e43ebfd243bcbad11be26bd921723027b77441","https://git.kernel.org/stable/c/6abd4698f4c8a78e7bbfc421205c060c199554a0","https://git.kernel.org/stable/c/9758ffe1c07b86aefd7ca8e40d9a461293427ca0","https://git.kernel.org/stable/c/d4d765f4761f9e3a2d62992f825aeee593bcb6b9","https://git.kernel.org/stable/c/f484a794e4ee2a9ce61f52a78e810ac45f3fe3b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52922 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: bcm: Fix UAF in bcm_proc_show() BUG: KASAN: slab-use-after-free in bcm_proc_show+0x969/0xa80 Read of size 8 at addr ffff888155846230 by task cat/7862 CPU: 1 PID: 7862 Comm: cat Not tainted 6.5.0-rc1-00153-gc8746099c197 #230 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xd5/0x150 print_report+0xc1/0x5e0 kasan_report+0xba/0xf0 bcm_proc_show+0x969/0xa80 seq_read_iter+0x4f6/0x1260 seq_read+0x165/0x210 proc_reg_read+0x227/0x300 vfs_read+0x1d5/0x8d0 ksys_read+0x11e/0x240 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Allocated by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x9e/0xa0 bcm_sendmsg+0x264b/0x44e0 sock_sendmsg+0xda/0x180 ____sys_sendmsg+0x735/0x920 ___sys_sendmsg+0x11d/0x1b0 __sys_sendmsg+0xfa/0x1d0 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 7846: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x27/0x40 ____kasan_slab_free+0x161/0x1c0 slab_free_freelist_hook+0x119/0x220 __kmem_cache_free+0xb4/0x2e0 rcu_core+0x809/0x1bd0 bcm_op is freed before procfs entry be removed in bcm_release(), this lead to bcm_proc_show() may read the freed bcm_op. | ["https://git.kernel.org/stable/c/11b8e27ed448baa385d90154a141466bd5e92f18","https://git.kernel.org/stable/c/3c3941bb1eb53abe7d640ffee5c4d6b559829ab3","https://git.kernel.org/stable/c/55c3b96074f3f9b0aee19bf93cd71af7516582bb","https://git.kernel.org/stable/c/9533dbfac0ff7edd77a5fa2c24974b1d66c8b0a6","https://git.kernel.org/stable/c/995f47d76647708ec26c6e388663ad4f3f264787","https://git.kernel.org/stable/c/9b58d36d0c1ea29a9571e0222a9c29df0ccfb7ff","https://git.kernel.org/stable/c/cf254b4f68e480e73dab055014e002b77aed30ed","https://git.kernel.org/stable/c/dfd0aa26e9a07f2ce546ccf8304ead6a2914e8a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46700 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix mes ring buffer overflow wait memory room until enough before writing mes packets to avoid ring buffer overflow. v2: squash in sched_hw_submission fix (cherry picked from commit 34e087e8920e635c62e2ed6a758b0cd27f836d13) | ["https://git.kernel.org/stable/c/11752c013f562a1124088a35bd314aa0e9f0e88f","https://git.kernel.org/stable/c/ed37550d7c516017c3b0324bdf144e2fa563ffb0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48980 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing() The SJA1105 family has 45 L2 policing table entries (SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110 (SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure but accounting for the difference in port count (5 in SJA1105 vs 10 in SJA1110) does not fully explain the difference. Rather, the SJA1110 also has L2 ingress policers for multicast traffic. If a packet is classified as multicast, it will be processed by the policer index 99 + SRCPORT. The sja1105_init_l2_policing() function initializes all L2 policers such that they don't interfere with normal packet reception by default. To have a common code between SJA1105 and SJA1110, the index of the multicast policer for the port is calculated because it's an index that is out of bounds for SJA1105 but in bounds for SJA1110, and a bounds check is performed. The code fails to do the proper thing when determining what to do with the multicast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast" index will be equal to 45, which is also equal to table->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passes through the check. But at the same time, SJA1105 doesn't have multicast policers. So the code programs the SHARINDX field of an out-of-bounds element in the L2 Policing table of the static config. The comparison between index 45 and 45 entries should have determined the code to not access this policer index on SJA1105, since its memory wasn't even allocated. With enough bad luck, the out-of-bounds write could even overwrite other valid kernel data, but in this case, the issue was detected using KASAN. Kernel log: sja1105 spi5.0: Probed switch chip: SJA1105Q ================================================================== BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340 Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8 ... Workqueue: events_unbound deferred_probe_work_func Call trace: ... sja1105_setup+0x1cbc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... Allocated by task 8: ... sja1105_setup+0x1bcc/0x2340 dsa_register_switch+0x1284/0x18d0 sja1105_probe+0x748/0x840 ... | ["https://git.kernel.org/stable/c/147f3e3d84054117ae6b9bf317ec4fda9f991192","https://git.kernel.org/stable/c/5e88c6f4aaa70c542e59e5a9d2244bcc99cd245d","https://git.kernel.org/stable/c/f8bac7f9fdb0017b32157957ffffd490f95faa07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53108 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8) | ["https://git.kernel.org/stable/c/0a326fbc8f72a320051f27328d4d4e7abdfe68d7","https://git.kernel.org/stable/c/16dd2825c23530f2259fc671960a3a65d2af69bd","https://git.kernel.org/stable/c/8db867061f4c76505ad62422b65d666b45289217"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49928 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. | ["https://git.kernel.org/stable/c/4007c3d2da31d0c755ea3fcf55e395118e5d5621","https://git.kernel.org/stable/c/83c84cdb75572048b67d6a3916283aeac865996e","https://git.kernel.org/stable/c/ed2e4bb17a4884cf29c3347353d8aabb7265b46c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49414 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix race condition between ext4_write and ext4_convert_inline_data Hulk Robot reported a BUG_ON: ================================================================== EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4_jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline] RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116 [...] Call Trace: ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795 generic_perform_write+0x279/0x3c0 mm/filemap.c:3344 ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520 do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732 do_iter_write+0x107/0x430 fs/read_write.c:861 vfs_writev fs/read_write.c:934 [inline] do_pwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ================================================================== Above issue may happen as follows: cpu1 cpu2 __________________________|__________________________ do_pwritev vfs_writev do_iter_write ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin vfs_fallocate ext4_fallocate ext4_convert_inline_data ext4_convert_inline_data_nolock ext4_destroy_inline_data_nolock clear EXT4_STATE_MAY_INLINE_DATA ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks ext4_mb_regular_allocator ext4_mb_good_group_nolock ext4_mb_init_group ext4_mb_init_cache ext4_mb_generate_buddy --> error ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_restore_inline_data set EXT4_STATE_MAY_INLINE_DATA ext4_block_write_begin ext4_da_write_end ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA) ext4_write_inline_data_end handle=NULL ext4_journal_stop(handle) __ext4_journal_stop ext4_put_nojournal(handle) ref_cnt = (unsigned long)handle BUG_ON(ref_cnt == 0) ---> BUG_ON The lock held by ext4_convert_inline_data is xattr_sem, but the lock held by generic_perform_write is i_rwsem. Therefore, the two locks can be concurrent. To solve above issue, we add inode_lock() for ext4_convert_inline_data(). At the same time, move ext4_convert_inline_data() in front of ext4_punch_hole(), remove similar handling from ext4_punch_hole(). | ["https://git.kernel.org/stable/c/14602353b350950b551eccc6b46411aa3b12ffe2","https://git.kernel.org/stable/c/18881d7e517169193d9ef6c89c7f322e3e164277","https://git.kernel.org/stable/c/725e00cb7039eae291890f1bb19bc867176745f6","https://git.kernel.org/stable/c/91f90b571f1a23f5b8a9c2b68a9aa5d6981a3c3d","https://git.kernel.org/stable/c/ccc6639f831bee91aa8b41c8a1cdd020ecfb9f32","https://git.kernel.org/stable/c/f87c7a4b084afc13190cbb263538e444cb2b392a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49572 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_slow_start_after_idle. While reading sysctl_tcp_slow_start_after_idle, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/0e3f82a03ec8c3808e87283e12946227415706c9","https://git.kernel.org/stable/c/369d99c2b89f54473adcf9acdf40ea562b5a6e0e","https://git.kernel.org/stable/c/3b26e11b07a09b31247688bec61e2925d4a571b6","https://git.kernel.org/stable/c/41aeba4506f6b70ec7500c6fe202731a4ba29fe5","https://git.kernel.org/stable/c/4845b5713ab18a1bb6e31d1fbb4d600240b8b691","https://git.kernel.org/stable/c/68b6f9506747d507c7bfa374d178929b4157e8c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49589 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_qrv. While reading sysctl_igmp_qrv, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv); | ["https://git.kernel.org/stable/c/8ebcc62c738f68688ee7c6fec2efe5bc6d3d7e60","https://git.kernel.org/stable/c/9eeb3a7702998bdccbfcc37997b5dd9215b9a7f7","https://git.kernel.org/stable/c/b399ffafffba39f47b731b26a5da1dc0ffc4b3ad","https://git.kernel.org/stable/c/c2954671010cd1127d1ffa328c6e6f8e99930982","https://git.kernel.org/stable/c/c721324afc589f8ea54bae04756b150aeaae5fa4","https://git.kernel.org/stable/c/e20dd1b0e0ea15bee1e528536a0840dba972ca0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48636 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held. | ["https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1","https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4","https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac","https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1","https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6","https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70","https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d","https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b","https://git.kernel.org/stable/c/2e473351400e3dd66f0b71eddcef82ee45a584c1","https://git.kernel.org/stable/c/49f401a98b318761ca2e15d4c7869a20043fbed4","https://git.kernel.org/stable/c/650a2e79d176db753654d3dde88e53a2033036ac","https://git.kernel.org/stable/c/aaba5ff2742043705bc4c02fd0b2b246e2e16da1","https://git.kernel.org/stable/c/d3a67c21b18f33c79382084af556557c442f12a6","https://git.kernel.org/stable/c/d86b4267834e6d4af62e3073e48166e349ab1b70","https://git.kernel.org/stable/c/db7ba07108a48c0f95b74fabbfd5d63e924f992d","https://git.kernel.org/stable/c/f5fcc9d6d71d9ff7fdbdd4b89074e6e24fffc20b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48949 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case. | ["https://git.kernel.org/stable/c/367e1e3399dbc56fc669740c4ab60e35da632b0e","https://git.kernel.org/stable/c/51fd5ede7ed42f272682a0c33d6f0767b3484a3d","https://git.kernel.org/stable/c/a6629659af3f5c6a91e3914ea62554c975ab77f4","https://git.kernel.org/stable/c/c383c7c35c7bc15e07a04eefa060a8a80cbeae29","https://git.kernel.org/stable/c/c581439a977545d61849a72e8ed631cfc8a2a3c1","https://git.kernel.org/stable/c/de5dc44370fbd6b46bd7f1a1e00369be54a041c8","https://git.kernel.org/stable/c/ef1d739dd1f362aec081278ff92f943c31eb177a","https://git.kernel.org/stable/c/f2479c3daaabccbac6c343a737615d0c595c6dc4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45828 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Mask ring interrupts before ring stop request Bus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt when the ring is being stopped. Depending on timing between ring stop request completion, interrupt handler removal and code execution this may lead to a NULL pointer dereference in hci_dma_irq_handler() if it gets to run after the io_data pointer is set to NULL in hci_dma_cleanup(). Prevent this my masking the ring interrupts before ring stop request. | ["https://git.kernel.org/stable/c/19cc5767334bfe980f52421627d0826c0da86721","https://git.kernel.org/stable/c/6ca2738174e4ee44edb2ab2d86ce74f015a0cc32","https://git.kernel.org/stable/c/9d745a56aea45e47f4755bc12e6429d6314dbb54","https://git.kernel.org/stable/c/a6cddf68b3405b272b5a3cad9657be0b02b34bf4","https://git.kernel.org/stable/c/a6dc4b4fda2e147e557050eaae51ff15edeb680b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: Fix mirred deadlock on device recursion When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below. [..... other info removed for brevity....] [ 82.890906] [ 82.890906] ============================================ [ 82.890906] WARNING: possible recursive locking detected [ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W [ 82.890906] -------------------------------------------- [ 82.890906] ping/418 is trying to acquire lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] but task is already holding lock: [ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [ 82.890906] [ 82.890906] other info that might help us debug this: [ 82.890906] Possible unsafe locking scenario: [ 82.890906] [ 82.890906] CPU0 [ 82.890906] ---- [ 82.890906] lock(&sch->q.lock); [ 82.890906] lock(&sch->q.lock); [ 82.890906] [ 82.890906] *** DEADLOCK *** [ 82.890906] [..... other info removed for brevity....] Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1 tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0 We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop. | ["https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11","https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef","https://git.kernel.org/stable/c/0f022d32c3eca477fbf79a205243a6123ed0fe11","https://git.kernel.org/stable/c/e6b90468da4dae2281a6e381107f411efb48b0ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50259 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly. | ["https://git.kernel.org/stable/c/27bd7a742e171362c9eb52ad5d1d71d3321f949f","https://git.kernel.org/stable/c/4ce1f56a1eaced2523329bef800d004e30f2f76c","https://git.kernel.org/stable/c/6a604877160fe5ab2e1985d5ce1ba6a61abe0693","https://git.kernel.org/stable/c/bcba86e03b3aac361ea671672cf48eed11f9011c","https://git.kernel.org/stable/c/c2150f666c6fc301d5d1643ed0f92251f1a0ff0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49945 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic. | ["https://git.kernel.org/stable/c/a0ffa68c70b367358b2672cdab6fa5bc4c40de2c","https://git.kernel.org/stable/c/dd41dab62f32d9e9e0669af8459d12a93834b238","https://git.kernel.org/stable/c/f6ca58696749268181f43150b3553f2bafd71e42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43855 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context. | ["https://git.kernel.org/stable/c/2d0738a8322bf4e5bfe693d16b3111928a9ccfbf","https://git.kernel.org/stable/c/32226070813140234b6c507084738e8e8385c5c6","https://git.kernel.org/stable/c/611d5cbc0b35a752e657a83eebadf40d814d006b","https://git.kernel.org/stable/c/ca963eefbc3331222b6121baa696d49ba2008811"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43895 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not. (cherry picked from commit 8151a6c13111b465dbabe07c19f572f7cbd16fef) | ["https://git.kernel.org/stable/c/282f0a482ee61d5e863512f3c4fcec90216c20d9","https://git.kernel.org/stable/c/50e376f1fe3bf571d0645ddf48ad37eb58323919","https://git.kernel.org/stable/c/70275bb960c71d313254473d38c14e7101cee5ad","https://git.kernel.org/stable/c/718d83f66fb07b2cab89a1fc984613a00e3db18f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43912 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: nl80211: disallow setting special AP channel widths Setting the AP channel width is meant for use with the normal 20/40/... MHz channel width progression, and switching around in S1G or narrow channels isn't supported. Disallow that. | ["https://git.kernel.org/stable/c/23daf1b4c91db9b26f8425cc7039cf96d22ccbfe","https://git.kernel.org/stable/c/3d42f2125f6c89e1e71c87b9f23412afddbba45e","https://git.kernel.org/stable/c/ac3bf6e47fd8da9bfe8027e1acfe0282a91584fc","https://git.kernel.org/stable/c/c6ea738e3feb407a3283197d9a25d0788f4f3cee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list. Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again. | ["https://git.kernel.org/stable/c/50d8009a0ac02c3311b23a0066511f8337bd88d9","https://git.kernel.org/stable/c/650e24748e1e0a7ff91d5c72b72a2f2a452b5b76","https://git.kernel.org/stable/c/7b379353e9144e1f7460ff15f39862012c9d0d78","https://git.kernel.org/stable/c/fba8334721e266f92079632598e46e5f89082f30"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39276 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() Syzbot reports a warning as follows: ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================ This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage. So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix. | ["https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21","https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e","https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb","https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483","https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16","https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577","https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8","https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9","https://git.kernel.org/stable/c/0c0b4a49d3e7f49690a6827a41faeffad5df7e21","https://git.kernel.org/stable/c/681ff9a09accd8a4379f8bd30b7a1641ee19bb3e","https://git.kernel.org/stable/c/76dc776153a47372719d664e0fc50d6355791abb","https://git.kernel.org/stable/c/896a7e7d0d555ad8b2b46af0c2fa7de7467f9483","https://git.kernel.org/stable/c/9ad75e78747b5a50dc5a52f0f8e92e920a653f16","https://git.kernel.org/stable/c/a95df6f04f2c37291adf26a74205cde0314d4577","https://git.kernel.org/stable/c/b37c0edef4e66fb21a2fbc211471195a383e5ab8","https://git.kernel.org/stable/c/e941b712e758f615d311946bf98216e79145ccd9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52806 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix possible null-ptr-deref when assigning a stream While AudioDSP drivers assign streams exclusively of HOST or LINK type, nothing blocks a user to attempt to assign a COUPLED stream. As supplied substream instance may be a stub, what is the case when code-loading, such scenario ends with null-ptr-deref. | ["https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250","https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7","https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4","https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd","https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e","https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323","https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b","https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236","https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0","https://git.kernel.org/stable/c/2527775616f3638f4fd54649eba8c7b84d5e4250","https://git.kernel.org/stable/c/25354bae4fc310c3928e8a42fda2d486f67745d7","https://git.kernel.org/stable/c/43b91df291c8802268ab3cfd8fccfdf135800ed4","https://git.kernel.org/stable/c/4a320da7f7cbdab2098b103c47f45d5061f42edd","https://git.kernel.org/stable/c/631a96e9eb4228ff75fce7e72d133ca81194797e","https://git.kernel.org/stable/c/758c7733cb821041f5fd403b7b97c0b95d319323","https://git.kernel.org/stable/c/7de25112de8222fd20564769e6c99dc9f9738a0b","https://git.kernel.org/stable/c/f93dc90c2e8ed664985e366aa6459ac83cdab236","https://git.kernel.org/stable/c/fe7c1a0c2b25c82807cb46fc3aadbf2664a682b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52809 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup() fc_lport_ptp_setup() did not check the return value of fc_rport_create() which can return NULL and would cause a NULL pointer dereference. Address this issue by checking return value of fc_rport_create() and log error message on fc_rport_create() failed. | ["https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba","https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f","https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b","https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106","https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa","https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e","https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00","https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01","https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34","https://git.kernel.org/stable/c/442fd24d7b6b29e4a9cd9225afba4142d5f522ba","https://git.kernel.org/stable/c/4df105f0ce9f6f30cda4e99f577150d23f0c9c5f","https://git.kernel.org/stable/c/56d78b5495ebecbb9395101f3be177cd0a52450b","https://git.kernel.org/stable/c/6b9ecf4e1032e645873933e5b43cbb84cac19106","https://git.kernel.org/stable/c/77072ec41d6ab3718c3fc639bc149b8037caedfa","https://git.kernel.org/stable/c/930f0aaba4820d6362de4e6ed569eaf444f1ea4e","https://git.kernel.org/stable/c/b549acf999824d4f751ca57965700372f2f3ad00","https://git.kernel.org/stable/c/bb83f79f90e92f46466adcfd4fd264a7ae0f0f01","https://git.kernel.org/stable/c/f6fe7261b92b21109678747f36df9fdab1e30c34"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48877 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: let's avoid panic if extent_tree is not created This patch avoids the below panic. pc : __lookup_extent_tree+0xd8/0x760 lr : f2fs_do_write_data_page+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: __lookup_extent_tree+0xd8/0x760 f2fs_do_write_data_page+0x104/0x87c f2fs_write_single_data_page+0x420/0xb60 f2fs_write_cache_pages+0x418/0xb1c __f2fs_write_data_pages+0x428/0x58c f2fs_write_data_pages+0x30/0x40 do_writepages+0x88/0x190 __writeback_single_inode+0x48/0x448 writeback_sb_inodes+0x468/0x9e8 __writeback_inodes_wb+0xb8/0x2a4 wb_writeback+0x33c/0x740 wb_do_writeback+0x2b4/0x400 wb_workfn+0xe4/0x34c process_one_work+0x24c/0x5bc worker_thread+0x3e8/0xa50 kthread+0x150/0x1b4 | ["https://git.kernel.org/stable/c/1c38cdc747f00daf7394535eae5afc4c503c59bb","https://git.kernel.org/stable/c/2c129e868992621a739bdd57a5bffa3985ef1b91","https://git.kernel.org/stable/c/557e85ff9afef6d45020b6f09357111d38033c31","https://git.kernel.org/stable/c/72009139a661ade5cb1da4239734ed02fa1cfff0","https://git.kernel.org/stable/c/dd83a9763e29ed7a21c8a43f7a62cd0a6bf74692","https://git.kernel.org/stable/c/df9d44b645b83fffccfb4e28c1f93376585fdec8","https://git.kernel.org/stable/c/ff85a1dbd90d29f73033177ff8d8de4a27d9721c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48891 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: regulator: da9211: Use irq handler when ready If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us. If we enable the IRQ handler before its structures are ready, we crash. This patch fixes: [ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blocking_notifier_call_chain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulator_notifier_call_chain+0x1c/0x2c [ 1.327825] da9211_irq_handler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154 | ["https://git.kernel.org/stable/c/02228f6aa6a64d588bc31e3267d05ff184d772eb","https://git.kernel.org/stable/c/1c1afcb8839b91c09d211ea304faa269763b1f91","https://git.kernel.org/stable/c/470f6a9175f13a53810734658c35cc5bba33be01","https://git.kernel.org/stable/c/ad1336274f733a7cb1f87b5c5908165a2c14df53","https://git.kernel.org/stable/c/d443308edbfb6e9e757b478af908515110d1efd5","https://git.kernel.org/stable/c/d4aa749e046435f054e94ebf50cad143d6229fae","https://git.kernel.org/stable/c/f75cde714e0a67f73ef169aa50d4ed77d04f7236"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52894 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate() In Google internal bug 265639009 we've received an (as yet) unreproducible crash report from an aarch64 GKI 5.10.149-android13 running device. AFAICT the source code is at: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10 The call stack is: ncm_close() -> ncm_notify() -> ncm_do_notify() with the crash at: ncm_do_notify+0x98/0x270 Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b) Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...): // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification) 0B 0D 00 79 strh w11, [x8, #6] // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request) 6C 0A 00 B9 str w12, [x19, #8] // x10 (NULL) was read here from offset 0 of valid pointer x9 // IMHO we're reading 'cdev->gadget' and getting NULL // gadget is indeed at offset 0 of struct usb_composite_dev 2A 01 40 F9 ldr x10, [x9] // loading req->buf pointer, which is at offset 0 of struct usb_request 69 02 40 F9 ldr x9, [x19] // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed 4B 5D 40 B9 ldr w11, [x10, #0x5c] which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment: event->wLength = cpu_to_le16(8); req->length = NCM_STATUS_BYTECOUNT; /* SPEED_CHANGE data is up/down speeds in bits/sec */ data = req->buf + sizeof *event; data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); My analysis of registers and NULL ptr deref crash offset (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c) heavily suggests that the crash is due to 'cdev->gadget' being NULL when executing: data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget)); which calls: ncm_bitrate(NULL) which then calls: gadget_is_superspeed(NULL) which reads ((struct usb_gadget *)NULL)->max_speed and hits a panic. AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C. (remember there's a GKI KABI reservation of 16 bytes in struct work_struct) It's not at all clear to me how this is all supposed to work... but returning 0 seems much better than panic-ing... | ["https://git.kernel.org/stable/c/09e4507ec8ef2d44da6ba4092b8ee2d81f216497","https://git.kernel.org/stable/c/63d161f29cd39c050e8873aa36e0c9fc013bb763","https://git.kernel.org/stable/c/a21da7f7aae618c785f7e4a275d43c06dc8412b6","https://git.kernel.org/stable/c/a69c8dfb85b44be9cc223be07d35cc3a9baefbea","https://git.kernel.org/stable/c/c6ec929595c7443250b2a4faea988c62019d5cd2","https://git.kernel.org/stable/c/e92c70059178da751e5af7de02384b7dfadb5ec7","https://git.kernel.org/stable/c/fef6b29671b66dfb71f17e337c1ad14b5a2cedae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Add exception protection processing for vd in axi_chan_handle_err function Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases. You can refer to the processing of axi_chan_block_xfer_complete function The triggered kernel panic is as follows: [ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axi_chan_handle_err+0xc4/0x230 [ 67.848491] lr : axi_chan_handle_err+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axi_chan_handle_err+0xc4/0x230 [ 67.848566] dw_axi_dma_interrupt+0xf4/0x590 [ 67.848569] __handle_irq_event_percpu+0x60/0x220 [ 67.848573] handle_irq_event+0x64/0x120 [ 67.848576] handle_fasteoi_irq+0xc4/0x220 [ 67.848580] __handle_domain_irq+0x80/0xe0 [ 67.848583] gic_handle_irq+0xc0/0x138 [ 67.848585] el1_irq+0xc8/0x180 [ 67.848588] arch_cpu_idle+0x14/0x2c [ 67.848591] default_idle_call+0x40/0x16c [ 67.848594] do_idle+0x1f0/0x250 [ 67.848597] cpu_startup_entry+0x2c/0x60 [ 67.848600] rest_init+0xc0/0xcc [ 67.848603] arch_call_rest_init+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]--- | ["https://git.kernel.org/stable/c/20d0a6d17e85a8a816a64fa7d7cae616f1617833","https://git.kernel.org/stable/c/5054d001ffaf76155637c5e5b922c11016cd6a5d","https://git.kernel.org/stable/c/51a7ad5b60efac65691729d10745c28fa1016b96","https://git.kernel.org/stable/c/53dd833fd0a2d8f0118d01ea063a70652689d31e","https://git.kernel.org/stable/c/57054fe516d59d03a7bcf1888e82479ccc244f87","https://git.kernel.org/stable/c/f534dc438828cc3f1f8c6895b8bdfbef079521fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52900 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix general protection fault in nilfs_btree_insert() If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave. When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted. By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be. | ["https://git.kernel.org/stable/c/0bf463939c09e5b2c35c71ed74a5fd60a74d6a04","https://git.kernel.org/stable/c/3c2a2ff67d46106715c2132021b98bd057c27545","https://git.kernel.org/stable/c/45627a1a6450662e1e0f8174ef07b05710a20062","https://git.kernel.org/stable/c/712bd74eccb9d3626a0a236641962eca8e11a243","https://git.kernel.org/stable/c/7633355e5c7f29c049a9048e461427d1d8ed3051","https://git.kernel.org/stable/c/b0ba060d3287108eba17603bee3810e4cf2c272d","https://git.kernel.org/stable/c/d9fde9eab1766170ff2ade67d09178d2cfd78749"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash. Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()") | ["https://git.kernel.org/stable/c/0143f282b15f7cedc0392ea10050fb6000fd16e6","https://git.kernel.org/stable/c/41b7181a40af84448a2b144fb02d8bf32b7e9a23","https://git.kernel.org/stable/c/6c01ef65de0b321b2db1ef9abf8f1d15862b937e","https://git.kernel.org/stable/c/7bf744f2de0a848fb1d717f5831b03db96feae89","https://git.kernel.org/stable/c/b2f54ed7739dfdf42c4df0a11131aad7c8635464","https://git.kernel.org/stable/c/b49c6e5dd236787f13a062ec528d724169f11152","https://git.kernel.org/stable/c/d9ef84a7c222497ecb5fdf93361c76931804825e","https://git.kernel.org/stable/c/fa58d9db5cad4bb7bb694b6837e3b96d87554f2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-36879 | Medium | N/A | An issue was discovered in the Linux kernel through 5.18.14. xfrm_expand_policies in net/xfrm/xfrm_policy.c can cause a refcount to be dropped twice. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901","https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=f85daf0e725358be78dfd208dea5fd665d8cb901","https://github.com/torvalds/linux/commit/f85daf0e725358be78dfd208dea5fd665d8cb901","https://lists.debian.org/debian-lts-announce/2022/09/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://security.netapp.com/advisory/ntap-20220901-0007/","https://www.debian.org/security/2022/dsa-5207"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21748 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix integer overflows on 32 bit systems On 32bit systems the addition operations in ipc_msg_alloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBD_IPC_MAX_PAYLOAD to avoid overflow. | ["https://git.kernel.org/stable/c/760568c1f62ea874e8fb492f9cfa4f47b4b8391e","https://git.kernel.org/stable/c/82f59d64e6297f270311b16b5dcf65be406d1ea3","https://git.kernel.org/stable/c/aab98e2dbd648510f8f51b83fbf4721206ccae45","https://git.kernel.org/stable/c/b4b902737746c490258de5cb55cab39e79927a67","https://git.kernel.org/stable/c/ecb9947fa7c99a77b04d43404c6988a0d326e4a0","https://git.kernel.org/stable/c/f3b9fb2764591d792d160f375851013665a9e820"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21667 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iomap: avoid avoid truncating 64-bit offset to 32 bits on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a 32-bit position due to folio_next_index() returning an unsigned long. This could lead to an infinite loop when writing to an xfs filesystem. | ["https://git.kernel.org/stable/c/402ce16421477e27f30b57d6d1a6dc248fa3a4e4","https://git.kernel.org/stable/c/7ca4bd6b754913910151acce00be093f03642725","https://git.kernel.org/stable/c/91371922704c8d82049ef7c2ad974d0a2cd1174d","https://git.kernel.org/stable/c/c13094b894de289514d84b8db56d1f2931a0bade"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26735 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family. | ["https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b","https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b","https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6","https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d","https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197","https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee","https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa","https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44","https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b457968a9b","https://git.kernel.org/stable/c/5559cea2d5aa3018a5f00dd2aca3427ba09b386b","https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6","https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d","https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197","https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee","https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa","https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241101-0012/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35997 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up The flag I2C_HID_READ_PENDING is used to serialize I2C operations. However, this is not necessary, because I2C core already has its own locking for that. More importantly, this flag can cause a lock-up: if the flag is set in i2c_hid_xfer() and an interrupt happens, the interrupt handler (i2c_hid_irq) will check this flag and return immediately without doing anything, then the interrupt handler will be invoked again in an infinite loop. Since interrupt handler is an RT task, it takes over the CPU and the flag-clearing task never gets scheduled, thus we have a lock-up. Delete this unnecessary flag. | ["https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1","https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401","https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722","https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497","https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22","https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e","https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8","https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003","https://git.kernel.org/stable/c/0561b65fbd53d3e788c5b0222d9112ca016fd6a1","https://git.kernel.org/stable/c/21bfca822cfc1e71796124e93b46e0d9fa584401","https://git.kernel.org/stable/c/29e94f295bad5be59cf4271a93e22cdcf5536722","https://git.kernel.org/stable/c/418c5575d56410c6e186ab727bf32ae32447d497","https://git.kernel.org/stable/c/5095b93021b899f54c9355bebf36d78854c33a22","https://git.kernel.org/stable/c/9c0f59e47a90c54d0153f8ddc0f80d7a36207d0e","https://git.kernel.org/stable/c/b65fb50e04a95eec34a9d1bc138454a98a5578d8","https://git.kernel.org/stable/c/c448a9fd50f77e8fb9156ff64848aa4295eb3003","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: flush pending destroy work before exit_net release Similar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroy work before netlink notifier") to address a race between exit_net and the destroy workqueue. The trace below shows an element to be released via destroy workqueue while exit_net path (triggered via module removal) has already released the set that is used in such transaction. [ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dump_stack_lvl+0x53/0x70 [ 1360.548014] print_report+0xc4/0x610 [ 1360.548026] ? __virt_addr_valid+0xba/0x160 [ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548176] kasan_report+0xae/0xe0 [ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables] [ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables] [ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30 [ 1360.548591] process_one_work+0x2f1/0x670 [ 1360.548610] worker_thread+0x4d3/0x760 [ 1360.548627] ? __pfx_worker_thread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? __pfx_kthread+0x10/0x10 [ 1360.548665] ret_from_fork+0x2f/0x50 [ 1360.548679] ? __pfx_kthread+0x10/0x10 [ 1360.548690] ret_from_fork_asm+0x1a/0x30 [ 1360.548707] </TASK> [ 1360.548719] Allocated by task 192061: [ 1360.548726] kasan_save_stack+0x20/0x40 [ 1360.548739] kasan_save_track+0x14/0x30 [ 1360.548750] __kasan_kmalloc+0x8f/0xa0 [ 1360.548760] __kmalloc_node+0x1f1/0x450 [ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables] [ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlink_unicast+0x367/0x4f0 [ 1360.548935] netlink_sendmsg+0x34b/0x610 [ 1360.548944] ____sys_sendmsg+0x4d4/0x510 [ 1360.548953] ___sys_sendmsg+0xc9/0x120 [ 1360.548961] __sys_sendmsg+0xbe/0x140 [ 1360.548971] do_syscall_64+0x55/0x120 [ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d [ 1360.548994] Freed by task 192222: [ 1360.548999] kasan_save_stack+0x20/0x40 [ 1360.549009] kasan_save_track+0x14/0x30 [ 1360.549019] kasan_save_free_info+0x3b/0x60 [ 1360.549028] poison_slab_object+0x100/0x180 [ 1360.549036] __kasan_slab_free+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables] [ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables] [ 1360.549221] ops_exit_list+0x50/0xa0 [ 1360.549229] free_exit_list+0x101/0x140 [ 1360.549236] unregister_pernet_operations+0x107/0x160 [ 1360.549245] unregister_pernet_subsys+0x1c/0x30 [ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables] [ 1360.549345] __do_sys_delete_module+0x253/0x370 [ 1360.549352] do_syscall_64+0x55/0x120 [ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d (gdb) list *__nft_release_table+0x473 0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354). 11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) { 11350 list_del(&flowtable->list); 11351 nft_use_dec(&table->use); 11352 nf_tables_flowtable_destroy(flowtable); 11353 } 11354 list_for_each_entry_safe(set, ns, &table->sets, list) { 11355 list_del(&set->list); 11356 nft_use_dec(&table->use); 11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT)) 11358 nft_map_deactivat ---truncated--- | ["https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2","https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7","https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31","https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e","https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6","https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86","https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49","https://git.kernel.org/stable/c/24cea9677025e0de419989ecb692acd4bb34cac2","https://git.kernel.org/stable/c/333b5085522cf1898d5a0d92616046b414f631a7","https://git.kernel.org/stable/c/46c4481938e2ca62343b16ea83ab28f4c1733d31","https://git.kernel.org/stable/c/4e8447a9a3d367b5065a0b7abe101da6e0037b6e","https://git.kernel.org/stable/c/d2c9eb19fc3b11caebafde4c30a76a49203d18a6","https://git.kernel.org/stable/c/f4e14695fe805eb0f0cb36e0ad6a560b9f985e86","https://git.kernel.org/stable/c/f7e3c88cc2a977c2b9a8aa52c1ce689e7b394e49","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-45871 | High | fixed |
|
An issue was discovered in drivers/net/ethernet/intel/igb/igb_main.c in the IGB driver in the Linux kernel before 6.5.3. A buffer size may not be adequate for frames larger than the MTU. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231110-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.3","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb5ed01cd2428cd25b1c88a3a9cba87055eb289f","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231110-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1462 | Medium | fixed |
|
An out-of-bounds read flaw was found in the Linux kernel’s TeleTYpe subsystem. The issue occurs in how a user triggers a race condition using ioctls TIOCSPTLCK and TIOCGPTPEER and TIOCSTI and TCXONC with leakage of memory in the flush_to_ldisc function. This flaw allows a local user to crash the system or read unauthorized random data from memory. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2078466","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://seclists.org/oss-sec/2022/q2/155","https://bugzilla.redhat.com/show_bug.cgi?id=2078466","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://seclists.org/oss-sec/2022/q2/155"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0382 | Medium | N/A | An information leak flaw was found due to uninitialized memory in the Linux kernel's TIPC protocol subsystem, in the way a user sends a TIPC datagram to one or more destinations. This flaw allows a local user to read some kernel memory. This issue is limited to no more than 7 bytes, and the user cannot control what is read. This flaw affects the Linux kernel versions prior to 5.17-rc1. | ["https://github.com/torvalds/linux/commit/d6d86830705f173fca6087a3e67ceaf68db80523","https://github.com/torvalds/linux/commit/d6d86830705f173fca6087a3e67ceaf68db80523"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53135 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the "load IA32_RTIT_CTL" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc. | ["https://git.kernel.org/stable/c/aa0d42cacf093a6fcca872edc954f6f812926a17","https://git.kernel.org/stable/c/b8a1d572478b6f239061ee9578b2451bf2f021c2","https://git.kernel.org/stable/c/b91bb0ce5cd7005b376eac690ec664c1b56372ec","https://git.kernel.org/stable/c/c3742319d021f5aa3a0a8c828485fee14753f6de","https://git.kernel.org/stable/c/d28b059ee4779b5102c5da6e929762520510e406","https://git.kernel.org/stable/c/d4b42f926adcce4e5ec193c714afd9d37bba8e5b","https://git.kernel.org/stable/c/e6716f4230a8784957273ddd27326264b27b9313"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50232 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero. | ["https://git.kernel.org/stable/c/0ac0beb4235a9a474f681280a3bd4e2a5bb66569","https://git.kernel.org/stable/c/3dc0eda2cd5c653b162852ae5f0631bfe4ca5e95","https://git.kernel.org/stable/c/4f588fffc307a4bc2761aee6ff275bb4b433e451","https://git.kernel.org/stable/c/efa353ae1b0541981bc96dbf2e586387d0392baa","https://git.kernel.org/stable/c/f51343f346e6abde094548a7fb34472b0d4cae91"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53058 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a | ["https://git.kernel.org/stable/c/07c9c26e37542486e34d767505e842f48f29c3f6","https://git.kernel.org/stable/c/58d23d835eb498336716cca55b5714191a309286","https://git.kernel.org/stable/c/66600fac7a984dea4ae095411f644770b2561ede","https://git.kernel.org/stable/c/a3ff23f7c3f0e13f718900803e090fd3997d6bc9","https://git.kernel.org/stable/c/ece593fc9c00741b682869d3f3dc584d37b7c9df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47684 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated--- | ["https://git.kernel.org/stable/c/09aea49fbc7e755a915c405644f347137cdb62b0","https://git.kernel.org/stable/c/16e0387d87fc858e34449fdf2b14ed5837f761db","https://git.kernel.org/stable/c/570f7d8c9bf14f041152ba8353d4330ef7575915","https://git.kernel.org/stable/c/5c4c03288a4aea705e36aa44119c13d7ee4dce99","https://git.kernel.org/stable/c/81d18c152e3f82bacadf83bc0a471b2363b9cc18","https://git.kernel.org/stable/c/96c4983eab2a5da235f7fff90beaf17b008ba029","https://git.kernel.org/stable/c/ad4f0a14d6856e68f023fc4e5017cfd881a3dfbc","https://git.kernel.org/stable/c/c8770db2d54437a5f49417ae7b46f7de23d14db6","https://git.kernel.org/stable/c/ec31cf42fc4e35bb1248ce6eb1de6de9f851ac86"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47699 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on. | ["https://git.kernel.org/stable/c/1d94dbdfbb64cc48d10dec65cc3c4fbf2497b343","https://git.kernel.org/stable/c/21839b6fbc3c41b3e374ecbdb0cabbbb2c53cf34","https://git.kernel.org/stable/c/24bf40740a3da6b4056721da34997ae6938f3da1","https://git.kernel.org/stable/c/2b78e9df10fb7f4e9d3d7a18417dd72fbbc1dfd0","https://git.kernel.org/stable/c/3644554d308ddf2669e459a1551a7edf60b2d62b","https://git.kernel.org/stable/c/73d23ecf234b7a6d47fb883f2dabe10e3230b31d","https://git.kernel.org/stable/c/9403001ad65ae4f4c5de368bdda3a0636b51d51a","https://git.kernel.org/stable/c/db73500d3f0e558eb642aae1d4782e7726b4a03f","https://git.kernel.org/stable/c/f68523e0f26faade18833fbef577a4295d8e2c94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47706 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | Λ | Λ | Λ | | | | | | V | V | V | bfqq1 bfqq2 bfqq3 process ref: 1 1 1 2) bfqq1 merged to bfqq2: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) | | | Λ \--------------\| | | V V | bfqq1--------->bfqq2 bfqq3 process ref: 0 2 1 3) bfqq2 merged to bfqq3: Process 1 Process 2 Process 3 (BIC1) (BIC2) (BIC3) here -> Λ | | \--------------\ \-------------\| V V bfqq1--------->bfqq2---------->bfqq3 process ref: 0 1 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 </TASK> Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated--- | ["https://git.kernel.org/stable/c/18ad4df091dd5d067d2faa8fce1180b79f7041a7","https://git.kernel.org/stable/c/6d130db286ad0ea392c96ebb2551acf0d7308048","https://git.kernel.org/stable/c/7faed2896d78e48ec96229e73b30b0af6c00a9aa","https://git.kernel.org/stable/c/880692ee233ba63808182705b3333403413b58f5","https://git.kernel.org/stable/c/8aa9de02a4be2e7006e636816ce19b0d667ceaa3","https://git.kernel.org/stable/c/a9bdd5b36887d2bacb8bc777fd18317c99fc2587","https://git.kernel.org/stable/c/bc2140534b2aae752e4f7cb4489642dbb5ec4777","https://git.kernel.org/stable/c/ddbdaad123254fb53e32480cb74a486a6868b1e0","https://git.kernel.org/stable/c/e1277ae780cca4e69ef5468d4582dfd48f0b8320"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47713 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled. | ["https://git.kernel.org/stable/c/04f75f5bae33349283d6886901d9acd2f110c024","https://git.kernel.org/stable/c/058c9026ad79dc98572442fd4c7e9a36aba6f596","https://git.kernel.org/stable/c/07eb0bd7b0a8abed9d45e0f567c9af1dc83e5268","https://git.kernel.org/stable/c/9d301de12da6e1bb069a9835c38359b8e8135121","https://git.kernel.org/stable/c/acb53a716e492a02479345157c43f21edc8bc64b","https://git.kernel.org/stable/c/ad4b7068b101fbbb4a9ca4b99b25eb051a9482ec","https://git.kernel.org/stable/c/db5ca4b42ccfa42d2af7b335ff12578e57775c02","https://git.kernel.org/stable/c/eab272972cffff9cd973b8e4055a8e81c64f7e6a","https://git.kernel.org/stable/c/f232916fab67ca1c3425926df4a866e59ff26908"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47737 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton <jlayton@kernel.org> | ["https://git.kernel.org/stable/c/3e8081ebff12bec1347deaceb6bce0765cce54df","https://git.kernel.org/stable/c/81821617312988096f5deccf0f7da6f888e98056","https://git.kernel.org/stable/c/8d0765f86135e27f0bb5c950c136495719b4c834","https://git.kernel.org/stable/c/9803ab882d565a8fb2dde5999d98866d1c499dfd","https://git.kernel.org/stable/c/9f03f0016ff797932551881c7e06ae50e9c39134","https://git.kernel.org/stable/c/a1afbbb5276f943ad7173d0b4c626b8c75a260da","https://git.kernel.org/stable/c/c6b16e700cf4d959af524bd9d3978407ff7ce462","https://git.kernel.org/stable/c/d078cbf5c38de83bc31f83c47dcd2184c04a50c7","https://git.kernel.org/stable/c/e32ee6a61041925d1a05c14d10352dcfce9ef029"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47749 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0d50ae281a1712b9b2ca72830a96b8f11882358d","https://git.kernel.org/stable/c/39cb9f39913566ec5865581135f3e8123ad1aee1","https://git.kernel.org/stable/c/4e1fe68d695af367506ea3c794c5969630f21697","https://git.kernel.org/stable/c/54aaa3ed40972511e423b604324b881425b9ff1e","https://git.kernel.org/stable/c/b11318dc8a1ec565300bb1a9073095af817cc508","https://git.kernel.org/stable/c/b12e25d91c7f97958341538c7dc63ee49d01548f","https://git.kernel.org/stable/c/b9c94c8ba5a713817cffd74c4bacc05187469624","https://git.kernel.org/stable/c/dd598ac57dcae796cb58551074660c39b43fb155","https://git.kernel.org/stable/c/e766e6a92410ca269161de059fff0843b8ddd65f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49877 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL. | ["https://git.kernel.org/stable/c/01cb2e751cc61ade454c9bc1aaa2eac1f8197112","https://git.kernel.org/stable/c/190d98bcd61117a78fe185222d162180f061a6ca","https://git.kernel.org/stable/c/33b525cef4cff49e216e4133cc48452e11c0391e","https://git.kernel.org/stable/c/46b1edf0536a5291a8ad2337f88c926214b209d9","https://git.kernel.org/stable/c/4846e72ab5a0726e49ad4188b9d9df091ae78c64","https://git.kernel.org/stable/c/61b84013e560382cbe7dd56758be3154d43a3988","https://git.kernel.org/stable/c/d52c5652e7dcb7a0648bbb8642cc3e617070ab49","https://git.kernel.org/stable/c/df944dc46d06af65a75191183d52be017e6b9dbe","https://git.kernel.org/stable/c/e68c8323355e8cedfbe0bec7d5a39009f61640b6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49944 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: <TASK> __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] | ["https://git.kernel.org/stable/c/0e4e2e60556c6ed00e8450b720f106a268d23062","https://git.kernel.org/stable/c/7f64cb5b4d8c872296eda0fdce3bcf099eec7aa7","https://git.kernel.org/stable/c/89bbead9d897c77d0b566349c8643030ff2abeba","https://git.kernel.org/stable/c/8beee4d8dee76b67c75dc91fd8185d91e845c160","https://git.kernel.org/stable/c/9230a59eda0878d7ecaa901d876aec76f57bd455","https://git.kernel.org/stable/c/dd70c8a89ef99c3d53127fe19e51ef47c3f860fa","https://git.kernel.org/stable/c/e7a8442195e8ebd97df467ce4742980ab57edcce","https://git.kernel.org/stable/c/e914bf68dab88815a7ae7b7a3a5e8913c8ff14a5","https://git.kernel.org/stable/c/f032e1dac30b3376c7d6026fb01a8c403c47a80d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49948 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len. | ["https://git.kernel.org/stable/c/1eebe602a8d8264a12e35e39d0645fa88dbbacdd","https://git.kernel.org/stable/c/2415f465730e48b6e38da1c7c097317bf5dd2d20","https://git.kernel.org/stable/c/27a8fabc54d2f960d47bdfbebf2bdc6e8a92a4c4","https://git.kernel.org/stable/c/473426a1d53a68dd1e718e6cd00d57936993fa6c","https://git.kernel.org/stable/c/566a931a1436d0e0ad13708ea55479b95426213c","https://git.kernel.org/stable/c/9b0ee571d20a238a22722126abdfde61f1b2bdd0","https://git.kernel.org/stable/c/ab9a9a9e9647392a19e7a885b08000e89c86b535","https://git.kernel.org/stable/c/d7d1a28f5dd57b4d83def876f8d7b4403bd37df9","https://git.kernel.org/stable/c/ff1c3cadcf405ab37dd91418a62a7acecf3bc5e2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49952 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f4ce4f7def9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 </TASK> | ["https://git.kernel.org/stable/c/38e3fd0c4a2616052eb3c8f4e6f32d1ff47cd663","https://git.kernel.org/stable/c/4e3542f40f3a94efa59ea328e307c50601ed7065","https://git.kernel.org/stable/c/50067d8b3f48e4cd4c9e817d3e9a5b5ff3507ca7","https://git.kernel.org/stable/c/531754952f5dfc4b141523088147071d6e6112c4","https://git.kernel.org/stable/c/752e1924604254f1708f3e3700283a86ebdd325d","https://git.kernel.org/stable/c/92ceba94de6fb4cee2bf40b485979c342f44a492","https://git.kernel.org/stable/c/b40b027a0c0cc1cb9471a13f9730bb2fff12a15b","https://git.kernel.org/stable/c/c0add6ed2cf1c4733cd489efc61faeccd3433b41","https://git.kernel.org/stable/c/f839c5cd348201fec440d987cbca9b979bdb4fa7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49957 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code. | ["https://git.kernel.org/stable/c/387bf565cc03e2e8c720b8b4798efea4aacb6962","https://git.kernel.org/stable/c/5784d9fcfd43bd853654bb80c87ef293b9e8e80a","https://git.kernel.org/stable/c/703b2c7e0798d263154dc8593dc2345f75dc077f","https://git.kernel.org/stable/c/82dfdd1e31e774578f76ce6dc90c834f96403a0f","https://git.kernel.org/stable/c/86a89e75e9e4dfa768b97db466ad6bedf2e7ea5b","https://git.kernel.org/stable/c/bf605ae98dab5c15c5b631d4d7f88898cb41b649","https://git.kernel.org/stable/c/f60e94a83db799bde625ac8671a5b4a6354e7120","https://git.kernel.org/stable/c/fd89d92c1140cee8f59de336cb37fa65e359c123","https://git.kernel.org/stable/c/ff55291fb36779819211b596da703389135f5b05"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49958 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the "Next Free Rec:" had overshot the "Count:" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix. | ["https://git.kernel.org/stable/c/020f5c53c17f66c0a8f2d37dad27ace301b8d8a1","https://git.kernel.org/stable/c/5c2072f02c0d75802ec28ec703b7d43a0dd008b5","https://git.kernel.org/stable/c/5c9807c523b4fca81d3e8e864dabc8c806402121","https://git.kernel.org/stable/c/5ca60b86f57a4d9648f68418a725b3a7de2816b0","https://git.kernel.org/stable/c/637c00e06564a945e9d0edb3d78d362d64935f9f","https://git.kernel.org/stable/c/74364cb578dcc0b6c9109519d19cbe5a56afac9a","https://git.kernel.org/stable/c/96ce4c3537114d1698be635f5e36c62dc49df7a4","https://git.kernel.org/stable/c/9f9a8f3ac65b4147f1a7b6c05fad5192c0e3c3d9","https://git.kernel.org/stable/c/aac31d654a0a31cb0d2fa36ae694f4e164a52707"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49959 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: <TASK> add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt when updating journal superblock fails") to make jbd2_cleanup_journal_tail return the correct error code. | ["https://git.kernel.org/stable/c/1c62dc0d82c62f0dc8fcdc4843208e522acccaf5","https://git.kernel.org/stable/c/3ced0fe6c0eff032733ea8b38778b34707270138","https://git.kernel.org/stable/c/481e8f18a290e39e04ddb7feb2bb2a2cc3b213ed","https://git.kernel.org/stable/c/70bae48377a2c4296fd3caf4caf8f11079111019","https://git.kernel.org/stable/c/801a35dfef6996f3d5eaa96a59caf00440d9165e","https://git.kernel.org/stable/c/c6bf043b210eac67d35a114e345c4e5585672913","https://git.kernel.org/stable/c/d5dc65370a746750dbb2f03eabcf86b18db65f32","https://git.kernel.org/stable/c/ec7f8337c98ad281020ad1f11ba492462d80737a","https://git.kernel.org/stable/c/f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49975 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. | ["https://git.kernel.org/stable/c/21cb47db1ec9765f91304763a24565ddc22d2492","https://git.kernel.org/stable/c/24141df5a8615790950deedd926a44ddf1dfd6d8","https://git.kernel.org/stable/c/2aa45f43709ba2082917bd2973d02687075b6eee","https://git.kernel.org/stable/c/34820304cc2cd1804ee1f8f3504ec77813d29c8e","https://git.kernel.org/stable/c/5b981d8335e18aef7908a068529a3287258ff6d8","https://git.kernel.org/stable/c/9634e8dc964a4adafa7e1535147abd7ec29441a6","https://git.kernel.org/stable/c/f31f92107e5a8ecc8902705122c594e979a351fe","https://git.kernel.org/stable/c/f561b48d633ac2e7d0d667020fc634a96ade33a0","https://git.kernel.org/stable/c/fe5e9182d3e227476642ae2b312e2356c4d326a3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. | ["https://git.kernel.org/stable/c/3b933b16c996af8adb6bc1b5748a63dfb41a82bc","https://git.kernel.org/stable/c/9e20d028d8d1deb1e7fed18f22ffc01669cf3237","https://git.kernel.org/stable/c/a8943969f9ead2fd3044fc826140a21622ef830e","https://git.kernel.org/stable/c/c98ab18b9f315ff977c2c65d7c71298ef98be8e3","https://git.kernel.org/stable/c/e58337100721f3cc0c7424a18730e4f39844934f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53131 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series "nilfs2: fix null-ptr-deref bugs on block tracepoints". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using "block:block_touch_buffer" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself. | ["https://git.kernel.org/stable/c/085556bf8c70e2629e02e79268dac3016a08b8bf","https://git.kernel.org/stable/c/19c71cdd77973f99a9adc3190130bc3aa7ae5423","https://git.kernel.org/stable/c/3b2a4fd9bbee77afdd3ed5a05a0c02b6cde8d3b9","https://git.kernel.org/stable/c/59b49ca67cca7b007a5afd3de0283c8008157665","https://git.kernel.org/stable/c/6438f3f42cda825f6f59b4e45ac3a1da28a6f2c9","https://git.kernel.org/stable/c/77e47f89d32c2d72eb33d0becbce7abe14d061f4","https://git.kernel.org/stable/c/b017697a517f8779ada4e8ce1c2c75dbf60a2636","https://git.kernel.org/stable/c/cd45e963e44b0f10d90b9e6c0e8b4f47f3c92471"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48896 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix pci device refcount leak As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak. | ["https://git.kernel.org/stable/c/112df4cd2b09acd64bcd18f5ef83ba5d07b34bf0","https://git.kernel.org/stable/c/4c93422a54cd6a349988f42e1c6bf082cf4ea9d8","https://git.kernel.org/stable/c/53cefa802f070d46c0c518f4865be2c749818a18","https://git.kernel.org/stable/c/b93fb4405fcb5112c5739c5349afb52ec7f15c07","https://git.kernel.org/stable/c/c49996c6aa03590e4ef5add8772cb6068d99fd59"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49906 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it. | ["https://git.kernel.org/stable/c/1b686053c06ffb9f4524b288110cf2a831ff7a25","https://git.kernel.org/stable/c/2002ccb93004e76a471b180560accb2c1f850f35","https://git.kernel.org/stable/c/ebef6616219ff04abdeb39450625f85419787ee3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49914 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877) | ["https://git.kernel.org/stable/c/65a6fee22d5cfa645cb05489892dc9cd3d142fc2","https://git.kernel.org/stable/c/68f75e6f08aad66069a629db8d7840919156c761","https://git.kernel.org/stable/c/8e4ed3cf1642df0c4456443d865cff61a9598aa8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50009 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/5493f9714e4cdaf0ee7cec15899a231400cb1a9f","https://git.kernel.org/stable/c/5f250d44b8191d612355dd97b89b37bbc1b5d2cb","https://git.kernel.org/stable/c/cd9f7bf6cad8b2d3876105ce3c9fc63460a046f6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46720 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix dereference after null check check the pointer hive before use. | ["https://git.kernel.org/stable/c/00b9594d6310eb33e14d3f07b54866499efe0d50","https://git.kernel.org/stable/c/0aad97bf6d0bc7a34a19f266b0b9fb2861efe64c","https://git.kernel.org/stable/c/1b73ea3d97cc23f9b16d10021782b48397d2b517","https://git.kernel.org/stable/c/b1f7810b05d1950350ac2e06992982974343e441"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52920 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: support non-r10 register spill/fill to/from stack in precision tracking Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present. Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/ | ["https://git.kernel.org/stable/c/199f0452873741fa4b8d4d88958e929030b2f92b","https://git.kernel.org/stable/c/41f6f64e6999a837048b1bd13a2f8742964eca6b","https://git.kernel.org/stable/c/ecc2aeeaa08a355d84d3ca9c3d2512399a194f29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48914 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen/netfront: destroy queues before real_num_tx_queues is zeroed xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 ("net-sysfs: update the queue counts in the unregistration path"), unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two facts together means, that xennet_destroy_queues() called from xennet_remove() cannot do its job, because it's called after unregister_netdev(). This results in kfree-ing queues that are still linked in napi, which ultimately crashes: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 RIP: 0010:free_netdev+0xa3/0x1a0 Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 Call Trace: <TASK> xennet_remove+0x13d/0x300 [xen_netfront] xenbus_dev_remove+0x6d/0xf0 __device_release_driver+0x17a/0x240 device_release_driver+0x24/0x30 bus_remove_device+0xd8/0x140 device_del+0x18b/0x410 ? _raw_spin_unlock+0x16/0x30 ? klist_iter_exit+0x14/0x20 ? xenbus_dev_request_and_reply+0x80/0x80 device_unregister+0x13/0x60 xenbus_dev_changed+0x18e/0x1f0 xenwatch_thread+0xc0/0x1a0 ? do_wait_intr_irq+0xa0/0xa0 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Fix this by calling xennet_destroy_queues() from xennet_uninit(), when real_num_tx_queues is still available. This ensures that queues are destroyed when real_num_tx_queues is set to 0, regardless of how unregister_netdev() was called. Originally reported at https://github.com/QubesOS/qubes-issues/issues/7257 | ["https://git.kernel.org/stable/c/198cdc287769c717dafff5887c6125cb7a373bf3","https://git.kernel.org/stable/c/47e2f166ed9fe17f24561d6315be2228f6a90209","https://git.kernel.org/stable/c/a1753d5c29a6fb9a8966dcf04cb4f3b71e303ae8","https://git.kernel.org/stable/c/a63eb1e4a2e1a191a90217871e67fba42fd39255","https://git.kernel.org/stable/c/b40c912624775a21da32d1105e158db5f6d0554a","https://git.kernel.org/stable/c/dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40965 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: lpi2c: Avoid calling clk_get_rate during transfer Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well. | ["https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e","https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a","https://git.kernel.org/stable/c/d038693e08adf9c162c6377800495e4f5a2df045","https://git.kernel.org/stable/c/2b42e9587a7a9c7b824e0feb92958f258263963e","https://git.kernel.org/stable/c/4268254a39484fc11ba991ae148bacbe75d9cc0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48947 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix u8 overflow By keep sending L2CAP_CONF_REQ packets, chan->num_conf_rsp increases multiple times and eventually it will wrap around the maximum number (i.e., 255). This patch prevents this by adding a boundary check with L2CAP_MAX_CONF_RSP Btmon log: Bluetooth monitor ver 5.64 = Note: Linux version 6.1.0-rc2 (x86_64) 0.264594 = Note: Bluetooth subsystem version 2.22 0.264636 @ MGMT Open: btmon (privileged) version 1.22 {0x0001} 0.272191 = New Index: 00:00:00:00:00:00 (Primary,Virtual,hci0) [hci0] 13.877604 @ RAW Open: 9496 (privileged) version 2.22 {0x0002} 13.890741 = Open Index: 00:00:00:00:00:00 [hci0] 13.900426 (...) > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #32 [hci0] 14.273106 invalid packet size (12 != 1033) 08 00 01 00 02 01 04 00 01 10 ff ff ............ > ACL Data RX: Handle 200 flags 0x00 dlen 1547 #33 [hci0] 14.273561 invalid packet size (14 != 1547) 0a 00 01 00 04 01 06 00 40 00 00 00 00 00 ........@..... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #34 [hci0] 14.274390 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 00 00 00 04 ........@....... > ACL Data RX: Handle 200 flags 0x00 dlen 2061 #35 [hci0] 14.274932 invalid packet size (16 != 2061) 0c 00 01 00 04 01 08 00 40 00 00 00 07 00 03 00 ........@....... = bluetoothd: Bluetooth daemon 5.43 14.401828 > ACL Data RX: Handle 200 flags 0x00 dlen 1033 #36 [hci0] 14.275753 invalid packet size (12 != 1033) 08 00 01 00 04 01 04 00 40 00 00 00 ........@... | ["https://git.kernel.org/stable/c/19a78143961a197de8502f4f29c453b913dc3c29","https://git.kernel.org/stable/c/49d5867819ab7c744852b45509e8469839c07e0e","https://git.kernel.org/stable/c/5550bbf709c323194881737fd290c4bada9e6ead","https://git.kernel.org/stable/c/95f1847a361c7b4bf7d74c06ecb6968455082c1a","https://git.kernel.org/stable/c/9fdc79b571434af7bc742da40a3405f038b637a7","https://git.kernel.org/stable/c/ad528fde0702903208d0a79d88d5a42ae3fc235b","https://git.kernel.org/stable/c/bcd70260ef56e0aee8a4fc6cd214a419900b0765","https://git.kernel.org/stable/c/f3fe6817156a2ad4b06f01afab04638a34d7c9a6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47518 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of the number of channels in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger a heap-based buffer overflow when copying the list of operating channels from Wi-Fi management frames. | ["https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/0cdfa9e6f0915e3d243e2393bfa8a22e12d553b0","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-5-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4208 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation. When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free. We recommend upgrading past commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://kernel.dance/3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0433 | Medium | N/A | A NULL pointer dereference flaw was found in the Linux kernel's BPF subsystem in the way a user triggers the map_get_next_key function of the BPF bloom filter. This flaw allows a local user to crash the system. This flaw affects Linux kernel versions prior to 5.17-rc1. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2048259","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3ccdcee28415c4226de05438b4d89eb5514edf73","https://lore.kernel.org/bpf/1640776802-22421-1-git-send-email-tcs.kernel%40gmail.com/t/","https://bugzilla.redhat.com/show_bug.cgi?id=2048259","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=3ccdcee28415c4226de05438b4d89eb5514edf73","https://lore.kernel.org/bpf/1640776802-22421-1-git-send-email-tcs.kernel%40gmail.com/t/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-14625 | High | N/A | A flaw was found in the Linux Kernel where an attacker may be able to have an uncontrolled read to kernel-memory from within a vm guest. A race condition between connect() and close() function may allow an attacker using the AF_VSOCK protocol to gather a 4 byte information leak or possibly intercept or corrupt AF_VSOCK messages destined to other clients. | ["https://access.redhat.com/errata/RHSA-2019:2029","https://access.redhat.com/errata/RHSA-2019:2043","https://access.redhat.com/errata/RHSA-2019:4154","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14625","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","https://usn.ubuntu.com/3872-1/","https://usn.ubuntu.com/3878-1/","https://usn.ubuntu.com/3878-2/","https://access.redhat.com/errata/RHSA-2019:2029","https://access.redhat.com/errata/RHSA-2019:2043","https://access.redhat.com/errata/RHSA-2019:4154","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14625","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://syzkaller.appspot.com/bug?extid=bd391451452fb0b93039","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","https://usn.ubuntu.com/3872-1/","https://usn.ubuntu.com/3878-1/","https://usn.ubuntu.com/3878-2/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6535 | High | N/A | A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6535","https://bugzilla.redhat.com/show_bug.cgi?id=2254053","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6535","https://bugzilla.redhat.com/show_bug.cgi?id=2254053","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0003/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2008-2544 | Medium | N/A | Mounting /proc filesystem via chroot command silently mounts it in read-write mode. The user could bypass the chroot environment and gain write access to files, he would never have otherwise. | ["https://bugzilla.redhat.com/show_bug.cgi?id=213135"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53124 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv(). | ["https://git.kernel.org/stable/c/073d89808c065ac4c672c0a613a71b27a80691cb","https://git.kernel.org/stable/c/3f51f8c9d28954cf380100883a02eed35a8277e9","https://git.kernel.org/stable/c/695fb0b9aecfd5dd5b2946ba8897ac2c1eef654d","https://git.kernel.org/stable/c/be7c61ea5f816168c38955eb4e898adc8b4b32fd","https://git.kernel.org/stable/c/c3d052cae566ec2285f5999958a5deb415a0f59e","https://git.kernel.org/stable/c/d285eb9d0641c8344f2836081b4ccb7b3c5cc1b6","https://git.kernel.org/stable/c/fe2c0bd6d1e29ccefdc978b9a290571c93c27473"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42123 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix double free err_addr pointer warnings In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages will be run many times so that double free err_addr in some special case. So set the err_addr to NULL to avoid the warnings. | ["https://git.kernel.org/stable/c/506c245f3f1cd989cb89811a7f06e04ff8813a0d","https://git.kernel.org/stable/c/8e24beb3c2b08a4763f920399a9cc577ed440a1a","https://git.kernel.org/stable/c/506c245f3f1cd989cb89811a7f06e04ff8813a0d","https://git.kernel.org/stable/c/8e24beb3c2b08a4763f920399a9cc577ed440a1a"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43872 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler. | ["https://git.kernel.org/stable/c/06580b33c183c9f98e2a2ca96a86137179032c08","https://git.kernel.org/stable/c/2fdf34038369c0a27811e7b4680662a14ada1d6b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50245 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir(). | ["https://git.kernel.org/stable/c/03b097099eef255fbf85ea6a786ae3c91b11f041","https://git.kernel.org/stable/c/34e3220efd666d49965a26840d39f27601ce70f4","https://git.kernel.org/stable/c/47e8a17491e37df53743bc2e72309f8f0d6224af","https://git.kernel.org/stable/c/c8e7d3b72ee57e43d58ba560fe7970dd840a4061","https://git.kernel.org/stable/c/f1bc362fe978952a9304bd0286788b0ae7724f14"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35806 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: fsl: qbman: Always disable interrupts when taking cgr_lock smp_call_function_single disables IRQs when executing the callback. To prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere. This is already done by qman_update_cgr and qman_delete_cgr; fix the other lockers. | ["https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397","https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f","https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3","https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a","https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03","https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd","https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9","https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec","https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430","https://git.kernel.org/stable/c/0e6521b0f93ff350434ed4ae61a250907e65d397","https://git.kernel.org/stable/c/276af8efb05c8e47acf2738a5609dd72acfc703f","https://git.kernel.org/stable/c/584c2a9184a33a40fceee838f856de3cffa19be3","https://git.kernel.org/stable/c/62c3ecd2833cff0eff4a82af4082c44ca8d2518a","https://git.kernel.org/stable/c/a62168653774c36398d65846a98034436ee66d03","https://git.kernel.org/stable/c/af25c5180b2b1796342798f6c56fcfd12f5035bd","https://git.kernel.org/stable/c/b56a793f267679945d1fdb9a280013bd2d0ed7f9","https://git.kernel.org/stable/c/dd199e5b759ffe349622a4b8fbcafc51fc51b1ec","https://git.kernel.org/stable/c/e6378314bb920acb39013051fa65d8f9f8030430","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56782 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: x86: Add adev NULL check to acpi_quirk_skip_serdev_enumeration() acpi_dev_hid_match() does not check for adev == NULL, dereferencing it unconditional. Add a check for adev being NULL before calling acpi_dev_hid_match(). At the moment acpi_quirk_skip_serdev_enumeration() is never called with a controller_parent without an ACPI companion, but better safe than sorry. | ["https://git.kernel.org/stable/c/4a49194f587a62d972b602e3e1a2c3cfe6567966","https://git.kernel.org/stable/c/e173bce05f7032a8b4964cfef82a4b7668f5f3af"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44972 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clear page dirty inside extent_write_locked_range() [BUG] For subpage + zoned case, the following workload can lead to rsv data leak at unmount time: # mkfs.btrfs -f -s 4k $dev # mount $dev $mnt # fsstress -w -n 8 -d $mnt -s 1709539240 0/0: fiemap - no filename 0/1: copyrange read - no filename 0/2: write - no filename 0/3: rename - no source filename 0/4: creat f0 x:0 0 0 0/4: creat add id=0,parent=-1 0/5: writev f0[259 1 0 0 0 0] [778052,113,965] 0 0/6: ioctl(FIEMAP) f0[259 1 0 0 224 887097] [1294220,2291618343991484791,0x10000] -1 0/7: dwrite - xfsctl(XFS_IOC_DIOINFO) f0[259 1 0 0 224 887097] return 25, fallback to stat() 0/7: dwrite f0[259 1 0 0 224 887097] [696320,102400] 0 # umount $mnt The dmesg includes the following rsv leak detection warning (all call trace skipped): ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8653 btrfs_destroy_inode+0x1e0/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8654 btrfs_destroy_inode+0x1a8/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- ------------[ cut here ]------------ WARNING: CPU: 2 PID: 4528 at fs/btrfs/inode.c:8660 btrfs_destroy_inode+0x1a0/0x200 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): last unmount of filesystem 1b4abba9-de34-4f07-9e7f-157cf12a18d6 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): space_info DATA has 268218368 free, is not full BTRFS info (device sda): space_info total=268435456, used=204800, pinned=0, reserved=0, may_use=12288, readonly=0 zone_unusable=0 BTRFS info (device sda): global_block_rsv: size 0 reserved 0 BTRFS info (device sda): trans_block_rsv: size 0 reserved 0 BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 4528 at fs/btrfs/block-group.c:4434 btrfs_free_block_groups+0x338/0x500 [btrfs] ---[ end trace 0000000000000000 ]--- BTRFS info (device sda): space_info METADATA has 267796480 free, is not full BTRFS info (device sda): space_info total=268435456, used=131072, pinned=0, reserved=0, may_use=262144, readonly=0 zone_unusable=245760 BTRFS info (device sda): global_block_rsv: size 0 reserved 0 BTRFS info (device sda): trans_block_rsv: size 0 reserved 0 BTRFS info (device sda): chunk_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_block_rsv: size 0 reserved 0 BTRFS info (device sda): delayed_refs_rsv: size 0 reserved 0 Above $dev is a tcmu-runner emulated zoned HDD, which has a max zone append size of 64K, and the system has 64K page size. [CAUSE] I have added several trace_printk() to show the events (header skipped): > btrfs_dirty_pages: r/i=5/259 dirty start=774144 len=114688 > btrfs_dirty_pages: r/i=5/259 dirty part of page=720896 off_in_page=53248 len_in_page=12288 > btrfs_dirty_pages: r/i=5/259 dirty part of page=786432 off_in_page=0 len_in_page=65536 > btrfs_dirty_pages: r/i=5/259 dirty part of page=851968 off_in_page=0 len_in_page=36864 The above lines show our buffered write has dirtied 3 pages of inode 259 of root 5: 704K 768K 832K 896K I |////I/////////////////I///////////| I 756K 868K |///| is the dirtied range using subpage bitmaps. and 'I' is the page boundary. Meanwhile all three pages (704K, 768K, 832K) have their PageDirty flag set. > btrfs_direct_write: r/i=5/259 start dio filepos=696320 len=102400 Then direct IO writ ---truncated--- | ["https://git.kernel.org/stable/c/97713b1a2ced1e4a2a6c40045903797ebd44d7e0","https://git.kernel.org/stable/c/ba4dedb71356638d8284e34724daca944be70368","https://git.kernel.org/stable/c/d3b403209f767e5857c1b9fda66726e6e6ffc99f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50099 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work. | ["https://git.kernel.org/stable/c/20cde998315a3d2df08e26079a3ea7501abce6db","https://git.kernel.org/stable/c/3728b4eb27910ffedd173018279a970705f2e03a","https://git.kernel.org/stable/c/9f1e7735474e7457a4d919a517900e46868ae5f6","https://git.kernel.org/stable/c/acc450aa07099d071b18174c22a1119c57da8227","https://git.kernel.org/stable/c/ad4bc35a6d22e9ff9b67d0d0c38bce654232f195","https://git.kernel.org/stable/c/ae743deca78d9e4b7f4f60ad2f95e20e8ea057f9","https://git.kernel.org/stable/c/bae792617a7e911477f67a3aff850ad4ddf51572","https://git.kernel.org/stable/c/cc86f2e9876c8b5300238cec6bf0bd8c842078ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46681 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood. | ["https://git.kernel.org/stable/c/5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf","https://git.kernel.org/stable/c/979b581e4c69257acab1af415ddad6b2d78a2fa5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46705 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe: reset mmio mappings with devm Set our various mmio mappings to NULL. This should make it easier to catch something rogue trying to mess with mmio after device removal. For example, we might unmap everything and then start hitting some mmio address which has already been unmamped by us and then remapped by something else, causing all kinds of carnage. | ["https://git.kernel.org/stable/c/b1c9fbed3884d3883021d699c7cdf5253a65543a","https://git.kernel.org/stable/c/c7117419784f612d59ee565145f722e8b5541fe6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52584 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spmi: mediatek: Fix UAF on device remove The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. | ["https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8","https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e","https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9","https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e","https://git.kernel.org/stable/c/521f28eedd6b14228c46e3b81e3bf9b90c2818d8","https://git.kernel.org/stable/c/9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e","https://git.kernel.org/stable/c/e821d50ab5b956ed0effa49faaf29912fd4106d9","https://git.kernel.org/stable/c/f8dcafcb54632536684336161da8bdd52120f95e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-27950 | Medium | fixed |
|
In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://www.openwall.com/lists/oss-security/2022/03/13/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe","https://www.openwall.com/lists/oss-security/2022/03/13/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56581 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: ref-verify: fix use-after-free after invalid ref action At btrfs_ref_tree_mod() after we successfully inserted the new ref entry (local variable 'ref') into the respective block entry's rbtree (local variable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF, we error out and free the ref entry without removing it from the block entry's rbtree. Then in the error path of btrfs_ref_tree_mod() we call btrfs_free_ref_cache(), which iterates over all block entries and then calls free_block_entry() for each one, and there we will trigger a use-after-free when we are called against the block entry to which we added the freed ref entry to its rbtree, since the rbtree still points to the block entry, as we didn't remove it from the rbtree before freeing it in the error path at btrfs_ref_tree_mod(). Fix this by removing the new ref entry from the rbtree before freeing it. Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i ---truncated--- | ["https://git.kernel.org/stable/c/4275ac2741941c9c7c2293619fdbacb9f70ba85b","https://git.kernel.org/stable/c/6370db28af9a8ae3bbdfe97f8a48f8f995e144cf","https://git.kernel.org/stable/c/6fd018aa168e472ce35be32296d109db6adb87ea","https://git.kernel.org/stable/c/7c4e39f9d2af4abaf82ca0e315d1fd340456620f","https://git.kernel.org/stable/c/a6f9e7a0bf1185c9070c0de03bb85eafb9abd650","https://git.kernel.org/stable/c/d2b85ce0561fde894e28fa01bd5d32820d585006","https://git.kernel.org/stable/c/dfb9fe7de61f34cc241ab3900bdde93341096e0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56595 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: add a check to prevent array-index-out-of-bounds in dbAdjTree When the value of lp is 0 at the beginning of the for loop, it will become negative in the next assignment and we should bail out. | ["https://git.kernel.org/stable/c/368a533152220b0a6f1142327d96c6b6361f3002","https://git.kernel.org/stable/c/3b5d21b56c3774bc84eab0a93aaac22a4475e2c4","https://git.kernel.org/stable/c/491487eeddccc4bb49f2e59d8c8f35bec89c15ca","https://git.kernel.org/stable/c/8a4311bbde702362fe7412045d06ab6767235dac","https://git.kernel.org/stable/c/a174706ba4dad895c40b1d2277bade16dfacdcd9","https://git.kernel.org/stable/c/a3d408870bc19b794646871bc4c3a5daa66f91c5","https://git.kernel.org/stable/c/b15000bcbecf27e0f7c0f149a409e5b865e28ca2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56596 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in jfs_readdir The stbl might contain some invalid values. Added a check to return error code in that case. | ["https://git.kernel.org/stable/c/839f102efb168f02dfdd46717b7c6dddb26b015e","https://git.kernel.org/stable/c/8ff7579554571d92e3deab168f5a7d7b146ed368","https://git.kernel.org/stable/c/97e693593162eef6851d232f0c8148169ed46a5c","https://git.kernel.org/stable/c/9efe72eefd4c4a7ce63b3e4d667d766d2b360cb4","https://git.kernel.org/stable/c/b62f41aeec9d250144c53875b507c1d45ae8c8fc","https://git.kernel.org/stable/c/e7d376f94f72b020f84e77278b150ec1cc27502c","https://git.kernel.org/stable/c/ff9fc48fab0e1ea0d423c23c99b91bba178f0b05"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56598 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: array-index-out-of-bounds fix in dtReadFirst The value of stbl can be sometimes out of bounds due to a bad filesystem. Added a check with appopriate return of error code in that case. | ["https://git.kernel.org/stable/c/22dcbf7661c6ffc3247978c254dc40b833a0d429","https://git.kernel.org/stable/c/25f1e673ef61d6bf9a6022e27936785896d74948","https://git.kernel.org/stable/c/2eea5fda5556ef03defebf07b0a12fcd2c5210f4","https://git.kernel.org/stable/c/823d573f5450ca6be80b36f54d1902ac7cd23fb9","https://git.kernel.org/stable/c/8c97a4d5463a1c972ef576ac499ea9b05f956097","https://git.kernel.org/stable/c/ca84a2c9be482836b86d780244f0357e5a778c46","https://git.kernel.org/stable/c/fd993b2180b4c373af8b99aa28d4dcda5c2a8f10"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56600 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: inet6: do not leave a dangling sk pointer in inet6_create() sock_init_data() attaches the allocated sk pointer to the provided sock object. If inet6_create() fails later, the sk object is released, but the sock object retains the dangling sk pointer, which may cause use-after-free later. Clear the sock sk pointer on error. | ["https://git.kernel.org/stable/c/276a473c956fb55a6f3affa9ff232e10fffa7b43","https://git.kernel.org/stable/c/35360255ca30776dee34d9fa764cffa24d0a5f65","https://git.kernel.org/stable/c/706b07b7b37f886423846cb38919132090bc40da","https://git.kernel.org/stable/c/79e16a0d339532ea832d85798eb036fc4f9e0cea","https://git.kernel.org/stable/c/9df99c395d0f55fb444ef39f4d6f194ca437d884","https://git.kernel.org/stable/c/f2709d1271cfdf55c670ab5c5982139ab627ddc7","https://git.kernel.org/stable/c/f44fceb71d72d29fb00e0ac84cdf9c081b03cd06"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56601 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: inet: do not leave a dangling sk pointer in inet_create() sock_init_data() attaches the allocated sk object to the provided sock object. If inet_create() fails later, the sk object is freed, but the sock object retains the dangling pointer, which may create use-after-free later. Clear the sk pointer in the sock object on error. | ["https://git.kernel.org/stable/c/25447c6aaa7235f155292b0c58a067347e8ae891","https://git.kernel.org/stable/c/2bc34d8c8898ae9fddf4612501aabb22d76c2b2c","https://git.kernel.org/stable/c/3e8258070b0f2aba66b3ef18883de229674fb288","https://git.kernel.org/stable/c/691d6d816f93b2a1008c14178399061466e674ef","https://git.kernel.org/stable/c/9365fa510c6f82e3aa550a09d0c5c6b44dbc78ff","https://git.kernel.org/stable/c/b4513cfd3a10c03c660d5d3d26c2e322efbfdd9b","https://git.kernel.org/stable/c/f8a3f255f7509a209292871715cda03779640c8d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56602 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: do not leave a dangling sk pointer in ieee802154_create() sock_init_data() attaches the allocated sk object to the provided sock object. If ieee802154_create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free. Clear the sk pointer in the sock object on error. | ["https://git.kernel.org/stable/c/03caa9bfb9fde97fb53d33decd7364514e6825cb","https://git.kernel.org/stable/c/14959fd7538b3be6d7617d9e60e404d6a8d4fd1f","https://git.kernel.org/stable/c/1d5fe782c0ff068d80933f9cfd0fd39d5434bbc9","https://git.kernel.org/stable/c/2b46994a6e76c8cc5556772932b9b60d03a55cd8","https://git.kernel.org/stable/c/b4982fbf13042e3bb33e04eddfea8b1506b5ea65","https://git.kernel.org/stable/c/b4fcd63f6ef79c73cafae8cf4a114def5fc3d80d","https://git.kernel.org/stable/c/e8bd6c5f5dc2234b4ea714380aedeea12a781754"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56603 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: af_can: do not leave a dangling sk pointer in can_create() On error can_create() frees the allocated sk object, but sock_init_data() has already attached it to the provided sock object. This will leave a dangling sk pointer in the sock object and may cause use-after-free later. | ["https://git.kernel.org/stable/c/1fe625f12d090d69f3f084990c7e4c1ff94bfe5f","https://git.kernel.org/stable/c/5947c9ac08f0771ea8ed64186b0d52e9029cb6c0","https://git.kernel.org/stable/c/811a7ca7320c062e15d0f5b171fe6ad8592d1434","https://git.kernel.org/stable/c/884ae8bcee749be43a071d6ed2d89058dbd2425c","https://git.kernel.org/stable/c/8df832e6b945e1ba61467d7f1c9305e314ae92fe","https://git.kernel.org/stable/c/ce39b5576785bb3e66591145aad03d66bc3e778d","https://git.kernel.org/stable/c/db207d19adbac96058685f6257720906ad41d215"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56605 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. | ["https://git.kernel.org/stable/c/61686abc2f3c2c67822aa23ce6f160467ec83d35","https://git.kernel.org/stable/c/7c4f78cdb8e7501e9f92d291a7d956591bf73be9","https://git.kernel.org/stable/c/8ad09ddc63ace3950ac43db6fbfe25b40f589dd6","https://git.kernel.org/stable/c/a8677028dd5123e5e525b8195483994d87123de4","https://git.kernel.org/stable/c/bb2f2342a6ddf7c04f9aefbbfe86104cd138e629","https://git.kernel.org/stable/c/daa13175a6dea312a76099066cb4cbd4fc959a84","https://git.kernel.org/stable/c/f6ad641646b67f29c7578dcd6c25813c7dcbf51e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56606 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: af_packet: avoid erroring out after sock_init_data() in packet_create() After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free. | ["https://git.kernel.org/stable/c/132e615bb1d7cdec2d3cfbdec2efa630e923fd21","https://git.kernel.org/stable/c/157f08db94123e2ba56877dd0ac88908b13a5dd0","https://git.kernel.org/stable/c/1dc1e1db927056cb323296e2294a855cd003dfe7","https://git.kernel.org/stable/c/46f2a11cb82b657fd15bab1c47821b635e03838b","https://git.kernel.org/stable/c/71b22837a5e55ac27d6a14b9cdf2326587405c4f","https://git.kernel.org/stable/c/a6cf750b737374454a4e03a5ed449a3eb0c96414","https://git.kernel.org/stable/c/fd09880b16d33aa5a7420578e01cd79148fa9829"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56642 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: Fix use-after-free of kernel socket in cleanup_bearer(). syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. [0][1] When bearer_disable() calls tipc_udp_disable(), cleanup of the UDP kernel socket is deferred by work calling cleanup_bearer(). tipc_exit_net() waits for such works to finish by checking tipc_net(net)->wq_count. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free. Let's move the decrement after releasing the socket in cleanup_bearer(). [0]: ref_tracker: net notrefcnt@000000009b3d1faf has 1/1 users at sk_alloc+0x438/0x608 inet_create+0x4c8/0xcb0 __sock_create+0x350/0x6b8 sock_create_kern+0x58/0x78 udp_sock_create4+0x68/0x398 udp_sock_create+0x88/0xc8 tipc_udp_enable+0x5e8/0x848 __tipc_nl_bearer_enable+0x84c/0xed8 tipc_nl_bearer_enable+0x38/0x60 genl_family_rcv_msg_doit+0x170/0x248 genl_rcv_msg+0x400/0x5b0 netlink_rcv_skb+0x1dc/0x398 genl_rcv+0x44/0x68 netlink_unicast+0x678/0x8b0 netlink_sendmsg+0x5e4/0x898 ____sys_sendmsg+0x500/0x830 [1]: BUG: KMSAN: use-after-free in udp_hashslot include/net/udp.h:85 [inline] BUG: KMSAN: use-after-free in udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 udp_hashslot include/net/udp.h:85 [inline] udp_lib_unhash+0x3b8/0x930 net/ipv4/udp.c:1979 sk_common_release+0xaf/0x3f0 net/core/sock.c:3820 inet_release+0x1e0/0x260 net/ipv4/af_inet.c:437 inet6_release+0x6f/0xd0 net/ipv6/af_inet6.c:489 __sock_release net/socket.c:658 [inline] sock_release+0xa0/0x210 net/socket.c:686 cleanup_bearer+0x42d/0x4c0 net/tipc/udp_media.c:819 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 Uninit was created at: slab_free_hook mm/slub.c:2269 [inline] slab_free mm/slub.c:4580 [inline] kmem_cache_free+0x207/0xc40 mm/slub.c:4682 net_free net/core/net_namespace.c:454 [inline] cleanup_net+0x16f2/0x19d0 net/core/net_namespace.c:647 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xcaf/0x1c90 kernel/workqueue.c:3310 worker_thread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 ret_from_fork+0x60/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244 CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer | ["https://git.kernel.org/stable/c/4e69457f9dfae67435f3ccf29008768eae860415","https://git.kernel.org/stable/c/650ee9a22d7a2de8999fac2d45983597a0c22359","https://git.kernel.org/stable/c/6a2fa13312e51a621f652d522d7e2df7066330b6","https://git.kernel.org/stable/c/d00d4470bf8c4282617a3a10e76b20a9c7e4cffa","https://git.kernel.org/stable/c/d2a4894f238551eae178904e7f45af87577074fd","https://git.kernel.org/stable/c/d62d5180c036eeac09f80660edc7a602b369125f","https://git.kernel.org/stable/c/e48b211c4c59062cb6dd6c2c37c51a7cc235a464"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56658 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: defer final 'struct net' free in netns dismantle Ilya reported a slab-use-after-free in dst_destroy [1] Issue is in xfrm6_net_init() and xfrm4_net_init() : They copy xfrm[46]_dst_ops_template into net->xfrm.xfrm[46]_dst_ops. But net structure might be freed before all the dst callbacks are called. So when dst_destroy() calls later : if (dst->ops->destroy) dst->ops->destroy(dst); dst->ops points to the old net->xfrm.xfrm[46]_dst_ops, which has been freed. See a relevant issue fixed in : ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") A fix is to queue the 'struct net' to be freed after one another cleanup_net() round (and existing rcu_barrier()) [1] BUG: KASAN: slab-use-after-free in dst_destroy (net/core/dst.c:112) Read of size 8 at addr ffff8882137ccab0 by task swapper/37/0 Dec 03 05:46:18 kernel: CPU: 37 UID: 0 PID: 0 Comm: swapper/37 Kdump: loaded Not tainted 6.12.0 #67 Hardware name: Red Hat KVM/RHEL, BIOS 1.16.1-1.el9 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:124) print_address_description.constprop.0 (mm/kasan/report.c:378) ? dst_destroy (net/core/dst.c:112) print_report (mm/kasan/report.c:489) ? dst_destroy (net/core/dst.c:112) ? kasan_addr_to_slab (mm/kasan/common.c:37) kasan_report (mm/kasan/report.c:603) ? dst_destroy (net/core/dst.c:112) ? rcu_do_batch (kernel/rcu/tree.c:2567) dst_destroy (net/core/dst.c:112) rcu_do_batch (kernel/rcu/tree.c:2567) ? __pfx_rcu_do_batch (kernel/rcu/tree.c:2491) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4339 kernel/locking/lockdep.c:4406) rcu_core (kernel/rcu/tree.c:2825) handle_softirqs (kernel/softirq.c:554) __irq_exit_rcu (kernel/softirq.c:589 kernel/softirq.c:428 kernel/softirq.c:637) irq_exit_rcu (kernel/softirq.c:651) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1049 arch/x86/kernel/apic/apic.c:1049) </IRQ> <TASK> asm_sysvec_apic_timer_interrupt (./arch/x86/include/asm/idtentry.h:702) RIP: 0010:default_idle (./arch/x86/include/asm/irqflags.h:37 ./arch/x86/include/asm/irqflags.h:92 arch/x86/kernel/process.c:743) Code: 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 6e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 0f 00 2d c7 c9 27 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 90 RSP: 0018:ffff888100d2fe00 EFLAGS: 00000246 RAX: 00000000001870ed RBX: 1ffff110201a5fc2 RCX: ffffffffb61a3e46 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb3d4d123 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed11c7e1835d R10: ffff888e3f0c1aeb R11: 0000000000000000 R12: 0000000000000000 R13: ffff888100d20000 R14: dffffc0000000000 R15: 0000000000000000 ? ct_kernel_exit.constprop.0 (kernel/context_tracking.c:148) ? cpuidle_idle_call (kernel/sched/idle.c:186) default_idle_call (./include/linux/cpuidle.h:143 kernel/sched/idle.c:118) cpuidle_idle_call (kernel/sched/idle.c:186) ? __pfx_cpuidle_idle_call (kernel/sched/idle.c:168) ? lock_release (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5848) ? lockdep_hardirqs_on_prepare (kernel/locking/lockdep.c:4347 kernel/locking/lockdep.c:4406) ? tsc_verify_tsc_adjust (arch/x86/kernel/tsc_sync.c:59) do_idle (kernel/sched/idle.c:326) cpu_startup_entry (kernel/sched/idle.c:423 (discriminator 1)) start_secondary (arch/x86/kernel/smpboot.c:202 arch/x86/kernel/smpboot.c:282) ? __pfx_start_secondary (arch/x86/kernel/smpboot.c:232) ? soft_restart_cpu (arch/x86/kernel/head_64.S:452) common_startup_64 (arch/x86/kernel/head_64.S:414) </TASK> Dec 03 05:46:18 kernel: Allocated by task 12184: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (./arch/x86/include/asm/current.h:49 mm/kasan/common.c:60 mm/kasan/common.c:69) __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345) kmem_cache_alloc_noprof (mm/slub.c:4085 mm/slub.c:4134 mm/slub.c:4141) copy_net_ns (net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces ---truncated--- | ["https://git.kernel.org/stable/c/0f6ede9fbc747e2553612271bce108f7517e7a45","https://git.kernel.org/stable/c/3267b254dc0a04dfa362a2be24573cfa6d2d78f5","https://git.kernel.org/stable/c/6610c7f8a8d47fd1123eed55ba8c11c2444d8842","https://git.kernel.org/stable/c/b7a79e51297f7b82adb687086f5cb2da446f1e40","https://git.kernel.org/stable/c/c261dcd61c9e88a8f1a66654354d32295a975230","https://git.kernel.org/stable/c/dac465986a4a38cd2f13e934f562b6ca344e5720"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56640 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix LGR and link use-after-free issue We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118 It is caused by repeated release of LGR/link refcnt. One suspect is that smc_conn_free() is called repeatedly because some smc_conn_free() from server listening path are not protected by sock lock. e.g. Calls under socklock | smc_listen_work ------------------------------------------------------- lock_sock(sk) | smc_conn_abort smc_conn_free | \- smc_conn_free \- smcr_link_put | \- smcr_link_put (duplicated) release_sock(sk) So here add sock lock protection in smc_listen_work() path, making it exclusive with other connection operations. | ["https://git.kernel.org/stable/c/0cf598548a6c36d90681d53c6b77d52363f2f295","https://git.kernel.org/stable/c/2c7f14ed9c19ec0f149479d1c2842ec1f9bf76d7","https://git.kernel.org/stable/c/673d606683ac70bc074ca6676b938bff18635226","https://git.kernel.org/stable/c/6f0ae06a234a78ae137064f2c89135ac078a00eb","https://git.kernel.org/stable/c/f502a88fdd415647a1f2dc45fac71b9c522a052b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50151 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix OOBs when building SMB2_IOCTL request When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2_set_next_command(). SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold the SMB2_IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2_set_next_command() will end up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb | ["https://git.kernel.org/stable/c/1ab60323c5201bef25f2a3dc0ccc404d9aca77f1","https://git.kernel.org/stable/c/2ef632bfb888d1a14f81c1703817951e0bec5531","https://git.kernel.org/stable/c/6f0516ef1290da24b85461ed08a0938af7415e49","https://git.kernel.org/stable/c/b209c3a0bc3ac172265c7fa8309e5d00654f2510","https://git.kernel.org/stable/c/e07d05b7f5ad9a503d9cab0afde2ab867bb65470","https://git.kernel.org/stable/c/ed31aba8ce93472d9e16f5cff844ae7c94e9601d","https://git.kernel.org/stable/c/fe92ddc1c32d4474e605e3a31a4afcd0e7d765ec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56538 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: zynqmp_kms: Unplug DRM device before removal Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver's internals. | ["https://git.kernel.org/stable/c/2e07c88914fc5289c21820b1aa94f058feb38197","https://git.kernel.org/stable/c/4fb97432e28a7e136b2d76135d50e988ada8e1af","https://git.kernel.org/stable/c/692f52aedccbf79b212a1e14e3735192b4c24a7d","https://git.kernel.org/stable/c/a17b9afe58c474657449cf87e238b1788200576b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56604 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). | ["https://git.kernel.org/stable/c/32df687e129ef0f9afcbcc914f7c32deb28fd481","https://git.kernel.org/stable/c/3945c799f12b8d1f49a3b48369ca494d981ac465","https://git.kernel.org/stable/c/6021ccc2471b7b95e29b7cfc7938e042bf56e281","https://git.kernel.org/stable/c/ac3eaac4cf142a15fe67be747a682b1416efeb6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53203 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential array underflow in ucsi_ccg_sync_control() The "command" variable can be controlled by the user via debugfs. The worry is that if con_index is zero then "&uc->ucsi->connector[con_index - 1]" would be an array underflow. | ["https://git.kernel.org/stable/c/0e66fd8e5a2e45c7dacfc9178ba702153f4a61a8","https://git.kernel.org/stable/c/56971710cd541f2f05160a84b3183477d34a1be9","https://git.kernel.org/stable/c/e15fd96c0b701c53f9006bcc836eaeb35a05a023","https://git.kernel.org/stable/c/e44189455c62469eb91d383ce9103d54c1f807a3","https://git.kernel.org/stable/c/e56aac6e5a25630645607b6856d4b2a17b2311a5","https://git.kernel.org/stable/c/ef92cd55289a282910575c5b9d87f646f2d39b38"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56631 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Fix slab-use-after-free read in sg_release() Fix a use-after-free bug in sg_release(), detected by syzbot with KASAN: BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5838 __mutex_unlock_slowpath+0xe2/0x750 kernel/locking/mutex.c:912 sg_release+0x1f4/0x2e0 drivers/scsi/sg.c:407 In sg_release(), the function kref_put(&sfp->f_ref, sg_remove_sfp) is called before releasing the open_rel_lock mutex. The kref_put() call may decrement the reference count of sfp to zero, triggering its cleanup through sg_remove_sfp(). This cleanup includes scheduling deferred work via sg_remove_sfp_usercontext(), which ultimately frees sfp. After kref_put(), sg_release() continues to unlock open_rel_lock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error. Move the kref_put(&sfp->f_ref, sg_remove_sfp) call after unlocking the open_rel_lock mutex. This ensures: - No references to sfp or sdp occur after the reference count is decremented. - Cleanup functions such as sg_remove_sfp() and sg_remove_sfp_usercontext() can safely execute without impacting the mutex handling in sg_release(). The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sg_release(). | ["https://git.kernel.org/stable/c/198b89dd5a595ee3f96e5ce5c448b0484cd0e53c","https://git.kernel.org/stable/c/1f5e2f1ca5875728fcf62bc1a054707444ab4960","https://git.kernel.org/stable/c/275b8347e21ab8193e93223a8394a806e4ba8918","https://git.kernel.org/stable/c/285ce1f89f8d414e7eecab5ef5118cd512596318","https://git.kernel.org/stable/c/59b30afa578637169e2819536bb66459fdddc39d","https://git.kernel.org/stable/c/e19acb1926c4a1f30ee1ec84d8afba2d975bd534","https://git.kernel.org/stable/c/f10593ad9bc36921f623361c9e3dd96bd52d85ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23559 | High | fixed |
|
In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/","https://security.netapp.com/advisory/ntap-20230302-0003/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b870e73a56c4cccbec33224233eaf295839f228c","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://patchwork.kernel.org/project/linux-wireless/patch/20230110173007.57110-1-szymon.heidrich%40gmail.com/","https://security.netapp.com/advisory/ntap-20230302-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50282 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434) | ["https://git.kernel.org/stable/c/2faaee36e6e30f9efc7fa6bcb0bdcbe05c23f51f","https://git.kernel.org/stable/c/4d75b9468021c73108b4439794d69e892b1d24e3","https://git.kernel.org/stable/c/673bdb4200c092692f83b5f7ba3df57021d52d29","https://git.kernel.org/stable/c/8906728f2fbd6504cb488f4afdd66af28f330a7a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56551 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix usage slab after free [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147 [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1 [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000016] Call Trace: [ +0.000008] <TASK> [ +0.000009] dump_stack_lvl+0x76/0xa0 [ +0.000017] print_report+0xce/0x5f0 [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] ? srso_return_thunk+0x5/0x5f [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200 [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000019] kasan_report+0xbe/0x110 [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000023] __asan_report_load8_noabort+0x14/0x30 [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched] [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? enable_work+0x124/0x220 [ +0.000015] ? __pfx_enable_work+0x10/0x10 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? free_large_kmalloc+0x85/0xf0 [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched] [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu] [ +0.000735] ? __kasan_check_read+0x11/0x20 [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu] [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu] [ +0.000679] ? mutex_unlock+0x80/0xe0 [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu] [ +0.000662] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_check_write+0x14/0x30 [ +0.000013] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? mutex_unlock+0x80/0xe0 [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu] [ +0.000663] drm_minor_release+0xc9/0x140 [drm] [ +0.000081] drm_release+0x1fd/0x390 [drm] [ +0.000082] __fput+0x36c/0xad0 [ +0.000018] __fput_sync+0x3c/0x50 [ +0.000014] __x64_sys_close+0x7d/0xe0 [ +0.000014] x64_sys_call+0x1bc6/0x2680 [ +0.000014] do_syscall_64+0x70/0x130 [ +0.000014] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? irqentry_exit+0x43/0x50 [ +0.000012] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? exc_page_fault+0x7c/0x110 [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ +0.000014] RIP: 0033:0x7ffff7b14f67 [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67 [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003 [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000 [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8 [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040 [ +0.000020] </TASK> [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s: [ +0.000014] kasan_save_stack+0x28/0x60 [ +0.000008] kasan_save_track+0x18/0x70 [ +0.000007] kasan_save_alloc_info+0x38/0x60 [ +0.000007] __kasan_kmalloc+0xc1/0xd0 [ +0.000007] kmalloc_trace_noprof+0x180/0x380 [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched] [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu] [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu] [ +0.000662] amdgpu_pci_p ---truncated--- | ["https://git.kernel.org/stable/c/05b1b33936b71e5f189a813a517f72e8a27fcb2f","https://git.kernel.org/stable/c/3990ef742c064e22189b954522930db04fc6b1a7","https://git.kernel.org/stable/c/3cc1116de10953f0265a05d9f351b02a9ec3b497","https://git.kernel.org/stable/c/6383199ada42d30562b4249c393592a2a9c38165","https://git.kernel.org/stable/c/b61badd20b443eabe132314669bb51a263982e5c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46815 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check num_valid_sets before accessing reader_wm_sets[] [WHY & HOW] num_valid_sets needs to be checked to avoid a negative index when accessing reader_wm_sets[num_valid_sets - 1]. This fixes an OVERRUN issue reported by Coverity. | ["https://git.kernel.org/stable/c/21f9cb44f8c60bf6c26487d428b1a09ad3e8aebf","https://git.kernel.org/stable/c/6a4a08e45e614cfa7a56498cdfaeb7fae2f07fa0","https://git.kernel.org/stable/c/7c47dd2e92341f2989ab73dbed07f8894593ad7b","https://git.kernel.org/stable/c/a72d4996409569027b4609414a14a87679b12267","https://git.kernel.org/stable/c/b36e9b3104c4ba0f2f5dd083dcf6159cb316c996","https://git.kernel.org/stable/c/b38a4815f79b87efb196cd5121579fc51e29a7fb","https://git.kernel.org/stable/c/c4a7f7c0062fe2c73f70bb7e335199e25bd71492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21791 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vrf: use RCU protection in l3mdev_l3_out() l3mdev_l3_out() can be called without RCU being held: raw_sendmsg() ip_push_pending_frames() ip_send_skb() ip_local_out() __ip_local_out() l3mdev_ip_out() Add rcu_read_lock() / rcu_read_unlock() pair to avoid a potential UAF. | ["https://git.kernel.org/stable/c/022cac1c693add610ae76ede03adf4d9d5a2cf21","https://git.kernel.org/stable/c/20a3489b396764cc9376e32a9172bee26a89dc3b","https://git.kernel.org/stable/c/5bb4228c32261d06e4fbece37ec3828bcc005b6b","https://git.kernel.org/stable/c/6ccaa5797f5362a2aad6baa6ddaf4715ac2dd51e","https://git.kernel.org/stable/c/6d0ce46a93135d96b7fa075a94a88fe0da8e8773","https://git.kernel.org/stable/c/7b81425b517accefd46bee854d94954f5c57e019","https://git.kernel.org/stable/c/c40cb5c03e37552d6eff963187109e2c3f78ef6f","https://git.kernel.org/stable/c/c7574740be8ce68a57d0aece24987b9be2114c3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53179 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix use-after-free of signing key Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race: task A task B cifs_mount() dfs_mount_share() get_session() cifs_mount_get_session() cifs_send_recv() cifs_get_smb_ses() compound_send_recv() cifs_setup_session() smb2_setup_request() kfree_sensitive() smb2_calc_signature() crypto_shash_setkey() *UAF* Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held. After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING. | ["https://git.kernel.org/stable/c/0e2b654a3848bf9da3b0d54c1ccf3f1b8c635591","https://git.kernel.org/stable/c/343d7fe6df9e247671440a932b6a73af4fa86d95","https://git.kernel.org/stable/c/39619c65ab4bbb3e78c818f537687653e112764d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21863 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent opcode speculation sqe->opcode is used for different tables, make sure we santitise it against speculations. | ["https://git.kernel.org/stable/c/1e988c3fe1264708f4f92109203ac5b1d65de50b","https://git.kernel.org/stable/c/506b9b5e8c2d2a411ea8fe361333f5081c56d23a","https://git.kernel.org/stable/c/b9826e3b26ec031e9063f64a7c735449c43955e4","https://git.kernel.org/stable/c/fdbfd52bd8b85ed6783365ff54c82ab7067bd61b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3777 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. When nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain's owner rule can also release the objects in certain circumstances. We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8. | ["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://kernel.dance/6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6817 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free. We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a. | ["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2023/12/22/13","http://www.openwall.com/lists/oss-security/2023/12/22/6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a","https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2023/12/22/13","http://www.openwall.com/lists/oss-security/2023/12/22/6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=317eb9685095678f2c9f5a8189de698c5354316a","https://kernel.dance/317eb9685095678f2c9f5a8189de698c5354316a","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48951 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Check bounds for second channel in snd_soc_put_volsw_sx() The bounds checks in snd_soc_put_volsw_sx() are only being applied to the first channel, meaning it is possible to write out of bounds values to the second channel in stereo controls. Add appropriate checks. | ["https://git.kernel.org/stable/c/1798b62d642e7b3d4ea3403914c3caf4e438465d","https://git.kernel.org/stable/c/18a168d85eadcfd45f015b5ecd2a97801b959e43","https://git.kernel.org/stable/c/50b5f6d4d9d2d69a7498c44fd8b26e13d73d3d98","https://git.kernel.org/stable/c/56288987843c3cb343e81e5fa51549cbaf541bd0","https://git.kernel.org/stable/c/9796d07c753164b7e6b0d7ef23fb4482840a9ef8","https://git.kernel.org/stable/c/97eea946b93961fffd29448dcda7398d0d51c4b2","https://git.kernel.org/stable/c/cf1c225f1927891ae388562b78ced7840c3723b9","https://git.kernel.org/stable/c/cf611d786796ec33da09d8c83d7d7f4e557b27de"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49029 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails Smatch report warning as follows: drivers/hwmon/ibmpex.c:509 ibmpex_register_bmc() warn: '&data->list' not removed from list If ibmpex_find_sensors() fails in ibmpex_register_bmc(), data will be freed, but data->list will not be removed from driver_data.bmc_data, then list traversal may cause UAF. Fix by removeing it from driver_data.bmc_data before free(). | ["https://git.kernel.org/stable/c/24b9633f7db7f4809be7053df1d2e117e7c2de10","https://git.kernel.org/stable/c/45f6e81863747c0d7bc6a95ec51129900e71467a","https://git.kernel.org/stable/c/798198273bf86673b970b51acdb35e57f42b3fcb","https://git.kernel.org/stable/c/7b2b67fe1339389e0bf3c37c7a677a004ac0e4e3","https://git.kernel.org/stable/c/90907cd4d11351ff76c9a447bcb5db0e264c47cd","https://git.kernel.org/stable/c/e2a87785aab0dac190ac89be6a9ba955e2c634f2","https://git.kernel.org/stable/c/e65cfd1f9cd27d9c27ee5cb88128a9f79f25d863","https://git.kernel.org/stable/c/f2a13196ad41c6c2ab058279dffe6c97292e753a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21855 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Don't reference skb after sending to VIOS Previously, after successfully flushing the xmit buffer to VIOS, the tx_bytes stat was incremented by the length of the skb. It is invalid to access the skb memory after sending the buffer to the VIOS because, at any point after sending, the VIOS can trigger an interrupt to free this memory. A race between reading skb->len and freeing the skb is possible (especially during LPM) and will result in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224 ================================================================== | ["https://git.kernel.org/stable/c/093b0e5c90592773863f300b908b741622eef597","https://git.kernel.org/stable/c/25dddd01dcc8ef3acff964dbb32eeb0d89f098e9","https://git.kernel.org/stable/c/501ac6a7e21b82e05207c6b4449812d82820f306","https://git.kernel.org/stable/c/abaff2717470e4b5b7c0c3a90e128b211a23da09","https://git.kernel.org/stable/c/bdf5d13aa05ec314d4385b31ac974d6c7e0997c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53088 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: "Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process. | ["https://git.kernel.org/stable/c/262dc6ea5f1eb18c4d08ad83d51222d0dd0dd42a","https://git.kernel.org/stable/c/6e046f4937474bc1b9fa980c1ad8f3253fc638f6","https://git.kernel.org/stable/c/7ad3fb3bfd43feb4e15c81dffd23ac4e55742791","https://git.kernel.org/stable/c/bf5f837d9fd27d32fb76df0a108babcaf4446ff1","https://git.kernel.org/stable/c/f30490e9695ef7da3d0899c6a0293cc7cd373567"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26583 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between async notify and socket close The submitting thread (one which called recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete() so any code past that point risks touching already freed data. Try to avoid the locking and extra flags altogether. Have the main thread hold an extra reference, this way we can depend solely on the atomic ref counter for synchronization. Don't futz with reiniting the completion, either, we are now tightly controlling when completion fires. | ["https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33","https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01","https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a","https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d","https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7","https://git.kernel.org/stable/c/6209319b2efdd8524691187ee99c40637558fa33","https://git.kernel.org/stable/c/7a3ca06d04d589deec81f56229a9a9d62352ce01","https://git.kernel.org/stable/c/86dc27ee36f558fe223dbdfbfcb6856247356f4a","https://git.kernel.org/stable/c/aec7961916f3f9e88766e2688992da6980f11b8d","https://git.kernel.org/stable/c/f17d21ea73918ace8afb9c2d8e734dbf71c2c9d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52898 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xhci: Fix null pointer dereference when host dies Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies. Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back. hold the xhci spinlock while freeing the virt device | ["https://git.kernel.org/stable/c/081105213ff6f661c114781d469233c7d0e09c2e","https://git.kernel.org/stable/c/133b902378e4acbd824c29dd0d48570ad596e368","https://git.kernel.org/stable/c/6fac4b5cecb3928a0a81069aaa815a2edc8dd5a1","https://git.kernel.org/stable/c/a2bc47c43e70cf904b1af49f76d572326c08bca7","https://git.kernel.org/stable/c/c462ac871f49753eca86bb960f573b993976a5ea","https://git.kernel.org/stable/c/ea2ee5e9991caf74e0604f994c1831a5867055b2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43866 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback. | ["https://git.kernel.org/stable/c/1b75da22ed1e6171e261bc9265370162553d5393","https://git.kernel.org/stable/c/5005e2e159b300c1b8c6820a1e13a62eb0127b9b","https://git.kernel.org/stable/c/6048dec754554a1303d632be6042d3feb3295285","https://git.kernel.org/stable/c/6b6c2ebd83f2bf97e8f221479372aaca97a4a9b2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33742 | High | fixed |
|
Linux disk/nic frontends data leaks T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Linux Block and Network PV device frontends don't zero memory regions before sharing them with the backend (CVE-2022-26365, CVE-2022-33740). Additionally the granularity of the grant table doesn't allow sharing less than a 4K page, leading to unrelated data residing in the same 4K page as data shared with a backend being accessible by such backend (CVE-2022-33741, CVE-2022-33742). | ["http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt","http://www.openwall.com/lists/oss-security/2022/07/05/6","http://xenbits.xen.org/xsa/advisory-403.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IGFTRZ66KQYTSYIRT5FRHF5D6O72NWOP/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RKRXZ4LHGCGMOG24ZCEJNY6R2BTS4S2Q/","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-403.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-45015 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable() For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set(). This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call. Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state. Patchwork: https://patchwork.freedesktop.org/patch/606729/ | ["https://git.kernel.org/stable/c/3bacf814b6a61cc683c68465f175ebd938f09c52","https://git.kernel.org/stable/c/3fb61718bcbe309279205d1cc275a6435611dc77","https://git.kernel.org/stable/c/aedf02e46eb549dac8db4821a6b9f0c6bf6e3990"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48844 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix leaking sent_cmd skb sent_cmd memory is not freed before freeing hci_dev causing it to leak it contents. | ["https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6","https://git.kernel.org/stable/c/9473d06bd1c8da49eafb685aa95a290290c672dd","https://git.kernel.org/stable/c/dd3b1dc3dd050f1f47cd13e300732852414270f8","https://git.kernel.org/stable/c/3679ccc09d8806686d579095ed504e045af7f7d6","https://git.kernel.org/stable/c/9473d06bd1c8da49eafb685aa95a290290c672dd","https://git.kernel.org/stable/c/dd3b1dc3dd050f1f47cd13e300732852414270f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26949 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: Fix NULL pointer dereference when get power limit Because powerplay_table initialization is skipped under sriov case, We check and set default lower and upper OD value if powerplay_table is NULL. | ["https://git.kernel.org/stable/c/08ae9ef829b8055c2fdc8cfee37510c1f4721a07","https://git.kernel.org/stable/c/99c2f1563b1400cc8331fc79d19ada1bb95bb388","https://git.kernel.org/stable/c/b8eaa8ef1f1157a9f330e36e66bdd7a693309948","https://git.kernel.org/stable/c/08ae9ef829b8055c2fdc8cfee37510c1f4721a07","https://git.kernel.org/stable/c/99c2f1563b1400cc8331fc79d19ada1bb95bb388","https://git.kernel.org/stable/c/b8eaa8ef1f1157a9f330e36e66bdd7a693309948"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36481 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing/probes: fix error check in parse_btf_field() btf_find_struct_member() might return NULL or an error via the ERR_PTR() macro. However, its caller in parse_btf_field() only checks for the NULL condition. Fix this by using IS_ERR() and returning the error up the stack. | ["https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0","https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a","https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb","https://git.kernel.org/stable/c/4ed468edfeb54c7202e559eba74c25fac6a0dad0","https://git.kernel.org/stable/c/ad4b202da2c498fefb69e5d87f67b946e7fe1e6a","https://git.kernel.org/stable/c/e569eb34970281438e2b48a3ef11c87459fcfbcb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39473 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension If a process module does not have base config extension then the same format applies to all of it's inputs and the process->base_config_ext is NULL, causing NULL dereference when specifically crafted topology and sequences used. | ["https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368","https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6","https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8","https://git.kernel.org/stable/c/9e16f17a2a0e97b43538b272e7071537a3e03368","https://git.kernel.org/stable/c/e3ae00ee238bce6cfa5ad935c921181c14d18fd6","https://git.kernel.org/stable/c/ffa077b2f6ad124ec3d23fbddc5e4b0ff2647af8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39483 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: WARN on vNMI + NMI window iff NMIs are outright masked When requesting an NMI window, WARN on vNMI support being enabled if and only if NMIs are actually masked, i.e. if the vCPU is already handling an NMI. KVM's ABI for NMIs that arrive simultanesouly (from KVM's point of view) is to inject one NMI and pend the other. When using vNMI, KVM pends the second NMI simply by setting V_NMI_PENDING, and lets the CPU do the rest (hardware automatically sets V_NMI_BLOCKING when an NMI is injected). However, if KVM can't immediately inject an NMI, e.g. because the vCPU is in an STI shadow or is running with GIF=0, then KVM will request an NMI window and trigger the WARN (but still function correctly). Whether or not the GIF=0 case makes sense is debatable, as the intent of KVM's behavior is to provide functionality that is as close to real hardware as possible. E.g. if two NMIs are sent in quick succession, the probability of both NMIs arriving in an STI shadow is infinitesimally low on real hardware, but significantly larger in a virtual environment, e.g. if the vCPU is preempted in the STI shadow. For GIF=0, the argument isn't as clear cut, because the window where two NMIs can collide is much larger in bare metal (though still small). That said, KVM should not have divergent behavior for the GIF=0 case based on whether or not vNMI support is enabled. And KVM has allowed simultaneous NMIs with GIF=0 for over a decade, since commit 7460fb4a3400 ("KVM: Fix simultaneous NMIs"). I.e. KVM's GIF=0 handling shouldn't be modified without a *really* good reason to do so, and if KVM's behavior were to be modified, it should be done irrespective of vNMI support. | ["https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1","https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6","https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356","https://git.kernel.org/stable/c/1d87cf2eba46deaff6142366127f2323de9f84d1","https://git.kernel.org/stable/c/b4bd556467477420ee3a91fbcba73c579669edc6","https://git.kernel.org/stable/c/f79edaf7370986d73d204b36c50cc563a4c0f356"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-39485 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Properly re-initialise notifier entry in unregister The notifier_entry of a notifier is not re-initialised after unregistering the notifier. This leads to dangling pointers being left there so use list_del_init() to return the notifier_entry an empty list. | ["https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66","https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb","https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a","https://git.kernel.org/stable/c/1aa6cd4adfc0380fa1ccc2f146848940ff882a66","https://git.kernel.org/stable/c/87100b09246202a91fce4a1562955c32229173bb","https://git.kernel.org/stable/c/9537a8425a7a0222999d5839a0b394b1e8834b4a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40997 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: fix memory leak on CPU EPP exit The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. [ rjw: Subject and changelog edits ] | ["https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd","https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582","https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81","https://git.kernel.org/stable/c/448efb7ea0bfa2c4e27c5a2eb5684fd225cd12cd","https://git.kernel.org/stable/c/8015c17fe11a8608cc3eb83d0ab831e1845a9582","https://git.kernel.org/stable/c/cea04f3d9aeebda9d9c063c0dfa71e739c322c81"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42074 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: amd: acp: add a null check for chip_pdev structure When acp platform device creation is skipped, chip->chip_pdev value will remain NULL. Add NULL check for chip->chip_pdev structure in snd_acp_resume() function to avoid null pointer dereference. | ["https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301","https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6","https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b","https://git.kernel.org/stable/c/98d919dfee1cc402ca29d45da642852d7c9a2301","https://git.kernel.org/stable/c/b0c39ae1cc86afe74aa2f6273ccb514f8d180cf6","https://git.kernel.org/stable/c/e158ed266fc1adfa456880fb6dabce2e5623843b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42135 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vhost_task: Handle SIGKILL by flushing work and exiting Instead of lingering until the device is closed, this has us handle SIGKILL by: 1. marking the worker as killed so we no longer try to use it with new virtqueues and new flush operations. 2. setting the virtqueue to worker mapping so no new works are queued. 3. running all the exiting works. | ["https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af","https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233","https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4","https://git.kernel.org/stable/c/abe067dc3a662eef7d5cddbbc41ed50a0b68b0af","https://git.kernel.org/stable/c/db5247d9bf5c6ade9fd70b4e4897441e0269b233","https://git.kernel.org/stable/c/dec987fe2df670827eb53b97c9552ed8dfc63ad4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42144 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/mediatek/lvts_thermal: Check NULL ptr on lvts_data Verify that lvts_data is not NULL before using it. | ["https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9","https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d","https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886","https://git.kernel.org/stable/c/79ef1a5593fdb8aa4dbccf6085c48f1739338bc9","https://git.kernel.org/stable/c/a1191a77351e25ddf091bb1a231cae12ee598b5d","https://git.kernel.org/stable/c/fd7ae1cabfedd727be5bee774c87acbc7b10b886"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-41009 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overrunning reservations in ringbuf The BPF ring buffer internally is implemented as a power-of-2 sized circular buffer, with two logical and ever-increasing counters: consumer_pos is the consumer counter to show which logical position the consumer consumed the data, and producer_pos which is the producer counter denoting the amount of data reserved by all producers. Each time a record is reserved, the producer that "owns" the record will successfully advance producer counter. In user space each time a record is read, the consumer of the data advanced the consumer counter once it finished processing. Both counters are stored in separate pages so that from user space, the producer counter is read-only and the consumer counter is read-write. One aspect that simplifies and thus speeds up the implementation of both producers and consumers is how the data area is mapped twice contiguously back-to-back in the virtual memory, allowing to not take any special measures for samples that have to wrap around at the end of the circular buffer data area, because the next page after the last data page would be first data page again, and thus the sample will still appear completely contiguous in virtual memory. Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for book-keeping the length and offset, and is inaccessible to the BPF program. Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ` for the BPF program to use. Bing-Jhong and Muhammad reported that it is however possible to make a second allocated memory chunk overlapping with the first chunk and as a result, the BPF program is now able to edit first chunk's header. For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in [0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets allocate a chunk B with size 0x3000. This will succeed because consumer_pos was edited ahead of time to pass the `new_prod_pos - cons_pos > rb->mask` check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data pages. This means that chunk B at [0x4000,0x4008] is chunk A's header. bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong page and could cause a crash. Fix it by calculating the oldest pending_pos and check whether the range from the oldest outstanding record to the newest would span beyond the ring buffer size. If that is the case, then reject the request. We've tested with the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh) before/after the fix and while it seems a bit slower on some benchmarks, it is still not significantly enough to matter. | ["https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686","https://git.kernel.org/stable/c/0f98f40eb1ed52af8b81f61901b6c0289ff59de4","https://git.kernel.org/stable/c/47416c852f2a04d348ea66ee451cbdcf8119f225","https://git.kernel.org/stable/c/511804ab701c0503b72eac08217eabfd366ba069","https://git.kernel.org/stable/c/be35504b959f2749bab280f4671e8df96dcf836f","https://git.kernel.org/stable/c/cfa1a2329a691ffd991fcf7248a57d752e712881","https://git.kernel.org/stable/c/d1b9df0435bc61e0b44f578846516df8ef476686"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50110 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix one more kernel-infoleak in algo dumping During fuzz testing, the following issue was discovered: BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81 Bytes 328-379 of 732 are uninitialized Memory access of size 732 starts at ffff88800e18e000 Data copied to user address 00007ff30f48aff0 CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Fixes copying of xfrm algorithms where some random data of the structure fields can end up in userspace. Padding in structures may be filled with random (possibly sensitve) data and should never be given directly to user-space. A similar issue was resolved in the commit 8222d5910dae ("xfrm: Zero padding when dumping algos and encap") Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/1e8fbd2441cb2ea28d6825f2985bf7d84af060bb","https://git.kernel.org/stable/c/610d4cea9b442b22b4820695fc3335e64849725e","https://git.kernel.org/stable/c/6889cd2a93e1e3606b3f6e958aa0924e836de4d2","https://git.kernel.org/stable/c/c73bca72b84b453c8d26a5e7673b20adb294bf54","https://git.kernel.org/stable/c/dc2ad8e8818e4bf1a93db78d81745b4877b32972"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50017 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence. | ["https://git.kernel.org/stable/c/a23823098ab2c277c14fc110b97d8d5c83597195","https://git.kernel.org/stable/c/cc31744a294584a36bf764a0ffa3255a8e69f036","https://git.kernel.org/stable/c/d113f9723f2bfd9c6feeb899b8ddbee6b8a6e01f","https://git.kernel.org/stable/c/d80a99892f7a992d103138fa4636b2c33abd6740"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43841 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. | ["https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414","https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29","https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d","https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942","https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d","https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a49f985c7","https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42157 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe sensitive data on failure Wipe sensitive data from stack also if the copy_to_user() fails. | ["https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9","https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581","https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02","https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487","https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad","https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250","https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575","https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0","https://git.kernel.org/stable/c/1d8c270de5eb74245d72325d285894a577a945d9","https://git.kernel.org/stable/c/4889f117755b2f18c23045a0f57977f3ec130581","https://git.kernel.org/stable/c/6e2e374403bf73140d0efc9541cb1b3bea55ac02","https://git.kernel.org/stable/c/90a01aefb84b09ccb6024d75d85bb8f620bd3487","https://git.kernel.org/stable/c/93c034c4314bc4c4450a3869cd5da298502346ad","https://git.kernel.org/stable/c/b5eb9176ebd4697bc248bf8d145e66d782cf5250","https://git.kernel.org/stable/c/c44a2151e5d21c66b070a056c26471f30719b575","https://git.kernel.org/stable/c/c51795885c801b6b7e976717e0d6d45b1e5be0f0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0516 | High | fixed |
|
A vulnerability was found in kvm_s390_guest_sida_op in the arch/s390/kvm/kvm-s390.c function in KVM for s390 in the Linux kernel. This flaw allows a local attacker with a normal user privilege to obtain unauthorized memory write access. This flaw affects Linux kernel versions prior to 5.17-rc4. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2050237","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55","https://security.netapp.com/advisory/ntap-20220331-0009/","https://www.debian.org/security/2022/dsa-5092","https://bugzilla.redhat.com/show_bug.cgi?id=2050237","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=09a93c1df3eafa43bcdfd7bf837c574911f12f55","https://security.netapp.com/advisory/ntap-20220331-0009/","https://www.debian.org/security/2022/dsa-5092"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49590 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: igmp: Fix data-races around sysctl_igmp_llm_reports. While reading sysctl_igmp_llm_reports, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. This test can be packed into a helper, so such changes will be in the follow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports)) | ["https://git.kernel.org/stable/c/1656ecaddf90e2a070ec2d2404cdae3edf80faca","https://git.kernel.org/stable/c/260446eb8e5541402b271343a4516f2b33dec1e4","https://git.kernel.org/stable/c/46307adceb67bdf2ec38408dd9cebc378a6b5c46","https://git.kernel.org/stable/c/473aad9ad57ff760005377e6f45a2ad4210e08ce","https://git.kernel.org/stable/c/a84b4afaca2573ed3aed1f8854aefe3ca5a82e72","https://git.kernel.org/stable/c/d77969e7d4ccc26bf1f414a39ef35050a83ba6d5","https://git.kernel.org/stable/c/ed876e99ccf417b8bd7fd8408ba5e8b008e46cc8","https://git.kernel.org/stable/c/f6da2267e71106474fbc0943dc24928b9cb79119"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49595 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_threshold. While reading sysctl_tcp_probe_threshold, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/44768749980d53bc01980d9c060f736808d11af0","https://git.kernel.org/stable/c/92c0aa4175474483d6cf373314343d4e624e882a","https://git.kernel.org/stable/c/96900fa61777402eb5056269d8000aace33a8b6c","https://git.kernel.org/stable/c/9b5dc7ad6da1373d3c60d4b869d688f996e5d219","https://git.kernel.org/stable/c/b04817c94fbd285a967d9b830b274fe9998c9c0b","https://git.kernel.org/stable/c/d452ce36f2d4c402fa3f5275c9677f80166e7fc6","https://git.kernel.org/stable/c/f524c3e7f6cdad66b3b6a912cef47b656f8b0de3","https://git.kernel.org/stable/c/fa5fb2cf9393db898772db8cb897ed5fd265eb78"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48869 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: gadgetfs: Fix race between mounting and unmounting The syzbot fuzzer and Gerald Lee have identified a use-after-free bug in the gadgetfs driver, involving processes concurrently mounting and unmounting the gadgetfs filesystem. In particular, gadgetfs_fill_super() can race with gadgetfs_kill_sb(), causing the latter to deallocate the_device while the former is using it. The output from KASAN says, in part: BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline] BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline] BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline] BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline] BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689 CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> ... atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] __refcount_sub_and_test include/linux/refcount.h:272 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs/super.c:1190 [inline] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [inline] The simplest solution is to ensure that gadgetfs_fill_super() and gadgetfs_kill_sb() are serialized by making them both acquire a new mutex. | ["https://git.kernel.org/stable/c/616fd34d017000ecf9097368b13d8a266f4920b3","https://git.kernel.org/stable/c/856e4b5e53f21edbd15d275dde62228dd94fb2b4","https://git.kernel.org/stable/c/9a39f4626b361ee7aa10fd990401c37ec3b466ae","https://git.kernel.org/stable/c/a2e075f40122d8daf587db126c562a67abd69cf9","https://git.kernel.org/stable/c/d18dcfe9860e842f394e37ba01ca9440ab2178f4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41850 | Medium | N/A | roccat_report_event in drivers/hid/hid-roccat.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free in certain situations where a report is received while copying a report->value is in progress. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cacdb14b1c8d3804a3a7d31773bc7569837b71a4","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/all/20220904193115.GA28134%40ubuntu/t/#u"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52884 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: cyapa - add missing input core locking to suspend/resume functions Grab input->mutex during suspend/resume functions like it is done in other input drivers. This fixes the following warning during system suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- ... ------------[ cut here ]------------ WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c Modules linked in: ... CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109 Hardware name: Samsung Exynos (Flattened Device Tree) Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28 Exception stack(0xf1625fb0 to 0xf1625ff8) ... ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6","https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7","https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd","https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc","https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75","https://git.kernel.org/stable/c/7b4e0b39182cf5e677c1fc092a3ec40e621c25b6","https://git.kernel.org/stable/c/9400caf566f65c703e99d95f87b00c4b445627a7","https://git.kernel.org/stable/c/a4c638ab25786bd5aab5978fe51b2b9be16a4ebd","https://git.kernel.org/stable/c/a5fc298fa8f67cf1f0e1fc126eab70578cd40adc","https://git.kernel.org/stable/c/f99809fdeb50d65bcbc1661ef391af94eebb8a75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35870 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in smb2_reconnect_server() The UAF bug is due to smb2_reconnect_server() accessing a session that is already being teared down by another thread that is executing __cifs_put_smb_ses(). This can happen when (a) the client has connection to the server but no session or (b) another thread ends up setting @ses->ses_status again to something different than SES_EXITING. To fix this, we need to make sure to unconditionally set @ses->ses_status to SES_EXITING and prevent any other threads from setting a new status while we're still tearing it down. The following can be reproduced by adding some delay to right after the ipc is freed in __cifs_put_smb_ses() - which will give smb2_reconnect_server() worker a chance to run and then accessing @ses->ipc: kinit ... mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10 [disconnect srv] ls /mnt/1 &>/dev/null sleep 30 kdestroy [reconnect srv] sleep 10 umount /mnt/1 ... CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed CIFS: VFS: \\srv Send error in SessSetup = -126 general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 Workqueue: cifsiod smb2_reconnect_server [cifs] RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0 Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad de 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 75 7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8 RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83 RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800 RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000 R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000 FS: 0000000000000000(0000) GS:ffff888157c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | ["https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa","https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5","https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0","https://git.kernel.org/stable/c/755fe68cd4b59e1d2a2dd3286177fd4404f57fed","https://git.kernel.org/stable/c/24a9799aa8efecd0eb55a75e35f9d8e6400063aa","https://git.kernel.org/stable/c/45f2beda1f1bc3d962ec07db1ccc3197c25499a5","https://git.kernel.org/stable/c/6202996a1c1887e83d0b3b0fcd86d0e5e6910ea0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47519 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing validation of IEEE80211_P2P_ATTR_OPER_CHANNEL in drivers/net/wireless/microchip/wilc1000/cfg80211.c in the WILC1000 wireless driver can trigger an out-of-bounds write when parsing the channel list attribute from Wi-Fi management frames. | ["https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/051ae669e4505abbe05165bebf6be7922de11f41","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-3-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47742 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing ".." path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously. | ["https://git.kernel.org/stable/c/28f1cd94d3f1092728fb775a0fe26c5f1ac2ebeb","https://git.kernel.org/stable/c/3d2411f4edcb649eaf232160db459bb4770b5251","https://git.kernel.org/stable/c/6c4e13fdfcab34811c3143a0a03c05fec4e870ec","https://git.kernel.org/stable/c/7420c1bf7fc784e587b87329cc6dfa3dca537aa4","https://git.kernel.org/stable/c/9b1ca33ebd05b3acef5b976c04e5e791af93ce1b","https://git.kernel.org/stable/c/a77fc4acfd49fc6076e565445b2bc5fdc3244da4","https://git.kernel.org/stable/c/c30558e6c5c9ad6c86459d9acce1520ceeab9ea6","https://git.kernel.org/stable/c/d1768e5535d3ded59f888637016e6f821f4e069f","https://git.kernel.org/stable/c/f0e5311aa8022107d63c54e2f03684ec097d1394"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53156 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service() I found the following bug in my fuzzer: UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath9k/htc_hst.c:26:51 index 255 is out of range for type 'htc_endpoint [22]' CPU: 0 UID: 0 PID: 8 Comm: kworker/0:0 Not tainted 6.11.0-rc6-dirty #14 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: events request_firmware_work_func Call Trace: <TASK> dump_stack_lvl+0x180/0x1b0 __ubsan_handle_out_of_bounds+0xd4/0x130 htc_issue_send.constprop.0+0x20c/0x230 ? _raw_spin_unlock_irqrestore+0x3c/0x70 ath9k_wmi_cmd+0x41d/0x610 ? mark_held_locks+0x9f/0xe0 ... Since this bug has been confirmed to be caused by insufficient verification of conn_rsp_epid, I think it would be appropriate to add a range check for conn_rsp_epid to htc_connect_service() to prevent the bug from occurring. | ["https://git.kernel.org/stable/c/3fe99b9690b99606d3743c9961ebee865cfa1ab8","https://git.kernel.org/stable/c/5f177fb9d01355ac183e65ad8909ea8ef734e0cf","https://git.kernel.org/stable/c/70eae50d2156cb6e078d0d78809b49bf2f4c7540","https://git.kernel.org/stable/c/8619593634cbdf5abf43f5714df49b04e4ef09ab","https://git.kernel.org/stable/c/8965db7fe2e913ee0802b05fc94c6d6aa74e0596","https://git.kernel.org/stable/c/b6551479daf2bfa80bfd5d9016b02a810e508bfb","https://git.kernel.org/stable/c/bc981179ab5d1a2715f35e3db4e4bb822bacc849","https://git.kernel.org/stable/c/c941af142200d975dd3be632aeb490f4cb91dae4","https://git.kernel.org/stable/c/cb480ae80fd4d0f1ac9e107ce799183beee5124b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53165 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sh: intc: Fix use-after-free bug in register_intc_controller() In the error handling for this function, d is freed without ever removing it from intc_list which would lead to a use after free. To fix this, let's only add it to the list after everything has succeeded. | ["https://git.kernel.org/stable/c/3c7c806b3eafd94ae0f77305a174d63b69ec187c","https://git.kernel.org/stable/c/588bdec1ff8b81517dbae0ae51c9df52c0b952d3","https://git.kernel.org/stable/c/63e72e551942642c48456a4134975136cdcb9b3c","https://git.kernel.org/stable/c/6ba6e19912570b2ad68298be0be1dc779014a303","https://git.kernel.org/stable/c/971b4893457788e0e123ea552f0bb126a5300e61","https://git.kernel.org/stable/c/b8b84dcdf3ab1d414304819f824b10efba64132c","https://git.kernel.org/stable/c/c3f4f4547fb291982f5ef56c048277c4d5ccc4e4","https://git.kernel.org/stable/c/c43df7dae28fb9fce96ef088250c1e3c3a77c527","https://git.kernel.org/stable/c/d8de818df12d86a1a26a8efd7b4b3b9c6dc3c5cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53173 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4.0: Fix a use-after-free problem in the asynchronous open() Yang Erkun reports that when two threads are opening files at the same time, and are forced to abort before a reply is seen, then the call to nfs_release_seqid() in nfs4_opendata_free() can result in a use-after-free of the pointer to the defunct rpc task of the other thread. The fix is to ensure that if the RPC call is aborted before the call to nfs_wait_on_sequence() is complete, then we must call nfs_release_seqid() in nfs4_open_release() before the rpc_task is freed. | ["https://git.kernel.org/stable/c/1cfae9575296f5040cdc84b0730e79078c081d2d","https://git.kernel.org/stable/c/229a30ed42bb87bcb044c5523fabd9e4f0e75648","https://git.kernel.org/stable/c/2ab9639f16b05d948066a6c4cf19a0fdc61046ff","https://git.kernel.org/stable/c/2fdb05dc0931250574f0cb0ebeb5ed8e20f4a889","https://git.kernel.org/stable/c/5237a297ffd374a1c4157a53543b7a69d7bbbc03","https://git.kernel.org/stable/c/7bf6bf130af8ee7d93a99c28a7512df3017ec759","https://git.kernel.org/stable/c/b56ae8e715557b4fc227c9381d2e681ffafe7b15","https://git.kernel.org/stable/c/ba6e6c04f60fe52d91520ac4d749d372d4c74521","https://git.kernel.org/stable/c/e2277a1d9d5cd0d625a4fd7c04fce2b53e66df77"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53194 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix use-after-free of slot->bus on hot remove Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886569c ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f3dbd ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist | ["https://git.kernel.org/stable/c/20502f0b3f3acd6bee300257556c27a867f80c8b","https://git.kernel.org/stable/c/41bbb1eb996be1435815aa1fbcc9ffc45b84cc12","https://git.kernel.org/stable/c/50473dd3b2a08601a078f852ea05572de9b1f86c","https://git.kernel.org/stable/c/69d2ceac11acf8579d58d55c9c5b65fb658f916e","https://git.kernel.org/stable/c/c7acef99642b763ba585f4a43af999fcdbcc3dc4","https://git.kernel.org/stable/c/c8266ab8e7ccd1d1f5a9c8b29eb2020175048134","https://git.kernel.org/stable/c/d0ddd2c92b75a19a37c887154223372b600fed37","https://git.kernel.org/stable/c/da6e6ff1f6c57f16e07af955e0e997fc90dd1e75","https://git.kernel.org/stable/c/e5d5c04aac71bf1476dc44b56f2206a4c2facca8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53227 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: bfa: Fix use-after-free in bfad_im_module_exit() BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20 Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303 Call Trace: <TASK> dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Above issue happens as follows: bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext; ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double release Don't call bfad_im_module_exit() if bfad_im_module_init() failed. | ["https://git.kernel.org/stable/c/0ceac8012d3ddea3317f0d82934293d05feb8af1","https://git.kernel.org/stable/c/178b8f38932d635e90f5f0e9af1986c6f4a89271","https://git.kernel.org/stable/c/1ffdde30a90bf8efe8f270407f486706962b3292","https://git.kernel.org/stable/c/3932c753f805a02e9364a4c58b590f21901f8490","https://git.kernel.org/stable/c/8f5a97443b547b4c83f876f1d6a11df0f1fd4efb","https://git.kernel.org/stable/c/a2b5035ab0e368e8d8a371e27fbc72f133c0bd40","https://git.kernel.org/stable/c/c28409f851abd93b37969cac7498828ad533afd9","https://git.kernel.org/stable/c/e76181a5be90abcc3ed8a300bd13878aa214d022","https://git.kernel.org/stable/c/ef2c2580189ea88a0dcaf56eb3a565763a900edb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53239 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: 6fire: Release resources at card release The current 6fire code tries to release the resources right after the call of usb6fire_chip_abort(). But at this moment, the card object might be still in use (as we're calling snd_card_free_when_closed()). For avoid potential UAFs, move the release of resources to the card's private_free instead of the manual call of usb6fire_chip_destroy() at the USB disconnect callback. | ["https://git.kernel.org/stable/c/0df7f4b5cc10f5adf98be0845372e9eef7bb5b09","https://git.kernel.org/stable/c/273eec23467dfbfbd0e4c10302579ba441fb1e13","https://git.kernel.org/stable/c/57860a80f03f9dc69a34a5c37b0941ad032a0a8c","https://git.kernel.org/stable/c/74357d0b5cd3ef544752bc9f21cbeee4902fae6c","https://git.kernel.org/stable/c/a0810c3d6dd2d29a9b92604d682eacd2902ce947","https://git.kernel.org/stable/c/b754e831a94f82f2593af806741392903f359168","https://git.kernel.org/stable/c/b889a7d68d7e76b8795b754a75c91a2d561d5e8c","https://git.kernel.org/stable/c/ea8cc56db659cf0ae57073e32a4735ead7bd7ee3","https://git.kernel.org/stable/c/f2d06d4e129e2508e356136f99bb20a332ff1a00"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49895 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max | ["https://git.kernel.org/stable/c/0d38a0751143afc03faef02d55d31f70374ff843","https://git.kernel.org/stable/c/ad89f83343a501890cf082c8a584e96b59fe4015","https://git.kernel.org/stable/c/bc50b614d59990747dd5aeced9ec22f9258991ff","https://git.kernel.org/stable/c/c4fdc2d6fea129684b82bab90bb52fbace494a58","https://git.kernel.org/stable/c/de6ee4f9e6b1c36b4fdc7c345c1a6de9e246093e","https://git.kernel.org/stable/c/f3ccd855b4395ce65f10dd37847167f52e122b70","https://git.kernel.org/stable/c/f5c3d306de91a4b69cfe3eedb72b42d452593e42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49969 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max | ["https://git.kernel.org/stable/c/0f1e222a4b41d77c442901d166fbdca967af0d86","https://git.kernel.org/stable/c/578422ddae3d13362b64e77ef9bab98780641631","https://git.kernel.org/stable/c/7ab69af56a23859b647dee69fa1052c689343621","https://git.kernel.org/stable/c/929506d5671419cffd8d01e9a7f5eae53682a838","https://git.kernel.org/stable/c/b9d8b94ec7e67f0cae228c054f77b73967c389a3","https://git.kernel.org/stable/c/c13f9c62015c56a938304cef6d507227ea3e0039","https://git.kernel.org/stable/c/d81873f9e715b72d4f8d391c8eb243946f784dfc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56548 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hfsplus: don't query the device logical block size multiple times Devices block sizes may change. One of these cases is a loop device by using ioctl LOOP_SET_BLOCK_SIZE. While this may cause other issues like IO being rejected, in the case of hfsplus, it will allocate a block by using that size and potentially write out-of-bounds when hfsplus_read_wrapper calls hfsplus_submit_bio and the latter function reads a different io_size. Using a new min_io_size initally set to sb_min_blocksize works for the purposes of the original fix, since it will be set to the max between HFSPLUS_SECTOR_SIZE and the first seen logical block size. We still use the max between HFSPLUS_SECTOR_SIZE and min_io_size in case the latter is not initialized. Tested by mounting an hfsplus filesystem with loop block sizes 512, 1024 and 4096. The produced KASAN report before the fix looks like this: [ 419.944641] ================================================================== [ 419.945655] BUG: KASAN: slab-use-after-free in hfsplus_read_wrapper+0x659/0xa0a [ 419.946703] Read of size 2 at addr ffff88800721fc00 by task repro/10678 [ 419.947612] [ 419.947846] CPU: 0 UID: 0 PID: 10678 Comm: repro Not tainted 6.12.0-rc5-00008-gdf56e0f2f3ca #84 [ 419.949007] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 419.950035] Call Trace: [ 419.950384] <TASK> [ 419.950676] dump_stack_lvl+0x57/0x78 [ 419.951212] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.951830] print_report+0x14c/0x49e [ 419.952361] ? __virt_addr_valid+0x267/0x278 [ 419.952979] ? kmem_cache_debug_flags+0xc/0x1d [ 419.953561] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.954231] kasan_report+0x89/0xb0 [ 419.954748] ? hfsplus_read_wrapper+0x659/0xa0a [ 419.955367] hfsplus_read_wrapper+0x659/0xa0a [ 419.955948] ? __pfx_hfsplus_read_wrapper+0x10/0x10 [ 419.956618] ? do_raw_spin_unlock+0x59/0x1a9 [ 419.957214] ? _raw_spin_unlock+0x1a/0x2e [ 419.957772] hfsplus_fill_super+0x348/0x1590 [ 419.958355] ? hlock_class+0x4c/0x109 [ 419.958867] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.959499] ? __pfx_string+0x10/0x10 [ 419.960006] ? lock_acquire+0x3e2/0x454 [ 419.960532] ? bdev_name.constprop.0+0xce/0x243 [ 419.961129] ? __pfx_bdev_name.constprop.0+0x10/0x10 [ 419.961799] ? pointer+0x3f0/0x62f [ 419.962277] ? __pfx_pointer+0x10/0x10 [ 419.962761] ? vsnprintf+0x6c4/0xfba [ 419.963178] ? __pfx_vsnprintf+0x10/0x10 [ 419.963621] ? setup_bdev_super+0x376/0x3b3 [ 419.964029] ? snprintf+0x9d/0xd2 [ 419.964344] ? __pfx_snprintf+0x10/0x10 [ 419.964675] ? lock_acquired+0x45c/0x5e9 [ 419.965016] ? set_blocksize+0x139/0x1c1 [ 419.965381] ? sb_set_blocksize+0x6d/0xae [ 419.965742] ? __pfx_hfsplus_fill_super+0x10/0x10 [ 419.966179] mount_bdev+0x12f/0x1bf [ 419.966512] ? __pfx_mount_bdev+0x10/0x10 [ 419.966886] ? vfs_parse_fs_string+0xce/0x111 [ 419.967293] ? __pfx_vfs_parse_fs_string+0x10/0x10 [ 419.967702] ? __pfx_hfsplus_mount+0x10/0x10 [ 419.968073] legacy_get_tree+0x104/0x178 [ 419.968414] vfs_get_tree+0x86/0x296 [ 419.968751] path_mount+0xba3/0xd0b [ 419.969157] ? __pfx_path_mount+0x10/0x10 [ 419.969594] ? kmem_cache_free+0x1e2/0x260 [ 419.970311] do_mount+0x99/0xe0 [ 419.970630] ? __pfx_do_mount+0x10/0x10 [ 419.971008] __do_sys_mount+0x199/0x1c9 [ 419.971397] do_syscall_64+0xd0/0x135 [ 419.971761] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 419.972233] RIP: 0033:0x7c3cb812972e [ 419.972564] Code: 48 8b 0d f5 46 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c2 46 0d 00 f7 d8 64 89 01 48 [ 419.974371] RSP: 002b:00007ffe30632548 EFLAGS: 00000286 ORIG_RAX: 00000000000000a5 [ 419.975048] RAX: ffffffffffffffda RBX: 00007ffe306328d8 RCX: 00007c3cb812972e [ 419.975701] RDX: 0000000020000000 RSI: 0000000020000c80 RDI: ---truncated--- | ["https://git.kernel.org/stable/c/06cbfbb13ac88f4154c2eb4bc4176f9d10139847","https://git.kernel.org/stable/c/1c82587cb57687de3f18ab4b98a8850c789bedcf","https://git.kernel.org/stable/c/21900e8478126ff6afe3b66679f676e74d1f8830","https://git.kernel.org/stable/c/2667c9b7b76efcbc7adbfea249892f20c313b0da","https://git.kernel.org/stable/c/3d7bda75e1a6239db053c73acde17ca146317824","https://git.kernel.org/stable/c/baccb5e12577b7a9eff54ffba301fdaa0f3ee5a8","https://git.kernel.org/stable/c/bfeecda050aa9376f642d5b2a71c4112cc6c8216","https://git.kernel.org/stable/c/e8a2b1c1c2ea85e9a5a2d0c5a5a7e7c639feb866","https://git.kernel.org/stable/c/f57725bcc5816425e25218fdf5fb6923bc578cdf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21700 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: Disallow replacing of child qdisc from one parent to another Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr step3. a class for nesting tc class add dev lo classid 1:2 drr step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024 step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr step7. tc class add dev lo classid 3:1 drr step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo step 9. Display the class/qdisc layout tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2 step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0 step 11. Redisplay again the qdiscs/classes tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2 Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it. Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003)) step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1 The semantics of "replace" is for a del/add _on the same node_ and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config". Joint work with Lion Ackermann <nnamrec@gmail.com> | ["https://git.kernel.org/stable/c/38646749d6e12f9d80a08d21ca39f0beca20230d","https://git.kernel.org/stable/c/46c59ec33ec98aba20c15117630cae43a01404cc","https://git.kernel.org/stable/c/73c7e1d6898ccbeee126194dcc05f58b8a795e70","https://git.kernel.org/stable/c/7e2bd8c13b07e29a247c023c7444df23f9a79fd8","https://git.kernel.org/stable/c/bc50835e83f60f56e9bec2b392fb5544f250fb6f","https://git.kernel.org/stable/c/cd796e269123e1994bfc4e99dd76680ba0946a97","https://git.kernel.org/stable/c/deda09c0543a66fa51554abc5ffd723d99b191bf","https://git.kernel.org/stable/c/fe18c21d67dc7d1bcce1bba56515b1b0306db19b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21692 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ets qdisc OOB Indexing Haowei Yan <g1042620637@gmail.com> found that ets_class_from_arg() can index an Out-Of-Bound class in ets_class_from_arg() when passed clid of 0. The overflow may cause local privilege escalation. [ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/sch_ets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'ets_class [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dump_stack_lvl+0xc2/0xf0 [ 18.859607] dump_stack+0x10/0x20 [ 18.860908] __ubsan_handle_out_of_bounds+0xa7/0xf0 [ 18.864022] ets_class_change+0x3d6/0x3f0 [ 18.864322] tc_ctl_tclass+0x251/0x910 [ 18.864587] ? lock_acquire+0x5e/0x140 [ 18.865113] ? __mutex_lock+0x9c/0xe70 [ 18.866009] ? __mutex_lock+0xa34/0xe70 [ 18.866401] rtnetlink_rcv_msg+0x170/0x6f0 [ 18.866806] ? __lock_acquire+0x578/0xc10 [ 18.867184] ? __pfx_rtnetlink_rcv_msg+0x10/0x10 [ 18.867503] netlink_rcv_skb+0x59/0x110 [ 18.867776] rtnetlink_rcv+0x15/0x30 [ 18.868159] netlink_unicast+0x1c3/0x2b0 [ 18.868440] netlink_sendmsg+0x239/0x4b0 [ 18.868721] ____sys_sendmsg+0x3e2/0x410 [ 18.869012] ___sys_sendmsg+0x88/0xe0 [ 18.869276] ? rseq_ip_fixup+0x198/0x260 [ 18.869563] ? rseq_update_cpu_node_id+0x10a/0x190 [ 18.869900] ? trace_hardirqs_off+0x5a/0xd0 [ 18.870196] ? syscall_exit_to_user_mode+0xcc/0x220 [ 18.870547] ? do_syscall_64+0x93/0x150 [ 18.870821] ? __memcg_slab_free_hook+0x69/0x290 [ 18.871157] __sys_sendmsg+0x69/0xd0 [ 18.871416] __x64_sys_sendmsg+0x1d/0x30 [ 18.871699] x64_sys_call+0x9e2/0x2670 [ 18.871979] do_syscall_64+0x87/0x150 [ 18.873280] ? do_syscall_64+0x93/0x150 [ 18.874742] ? lock_release+0x7b/0x160 [ 18.876157] ? do_user_addr_fault+0x5ce/0x8f0 [ 18.877833] ? irqentry_exit_to_user_mode+0xc2/0x210 [ 18.879608] ? irqentry_exit+0x77/0xb0 [ 18.879808] ? clear_bhb_loop+0x15/0x70 [ 18.880023] ? clear_bhb_loop+0x15/0x70 [ 18.880223] ? clear_bhb_loop+0x15/0x70 [ 18.880426] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]--- | ["https://git.kernel.org/stable/c/03c56665dab1f4ac844bc156652d50d639093fa5","https://git.kernel.org/stable/c/1332c6ed446be787f901ed1064ec6a3c694f028a","https://git.kernel.org/stable/c/997f6ec4208b23c87daf9f044689685f091826f7","https://git.kernel.org/stable/c/bcf0d815e728a3a304b50455b32a3170c16e1eaa","https://git.kernel.org/stable/c/d62b04fca4340a0d468d7853bd66e511935a18cb","https://git.kernel.org/stable/c/f4168299e553f17aa2ba4016e77a9c38da40eb1d","https://git.kernel.org/stable/c/f6b0f05fbfa4044f890e8a348288c0d9a20bd1d0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-36978 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: sch_multiq: fix possible OOB write in multiq_tune() q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur. | ["https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882","https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f","https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e","https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3","https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d","https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d","https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129","https://git.kernel.org/stable/c/0f208fad86631e005754606c3ec80c0d44a11882","https://git.kernel.org/stable/c/52b1aa07cda6a199cd6754d3798c7759023bc70f","https://git.kernel.org/stable/c/54c2c171c11a798fe887b3ff72922aa9d1411c1e","https://git.kernel.org/stable/c/598572c64287aee0b75bbba4e2881496878860f3","https://git.kernel.org/stable/c/affc18fdc694190ca7575b9a86632a73b9fe043d","https://git.kernel.org/stable/c/d5d9d241786f49ae7cbc08e7fc95a115e9d80f3d","https://git.kernel.org/stable/c/d6fb5110e8722bc00748f22caeb650fe4672f129"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50048 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { uint8_t type; struct tiocl_selection ts; }; int main() { struct fb_con2fbmap con2fb; struct param param; int fd = open("/dev/fb1", 0, 0); con2fb.console = 0x19; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); param.type = 2; param.ts.xs = 0; param.ts.ys = 0; param.ts.xe = 0; param.ts.ye = 0; param.ts.sel_mode = 0; int fd1 = open("/dev/tty1", O_RDWR, 0); ioctl(fd1, TIOCLINUX, ¶m); con2fb.console = 1; con2fb.framebuffer = 0; ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); return 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs. | ["https://git.kernel.org/stable/c/5b97eebcce1b4f3f07a71f635d6aa3af96c236e7","https://git.kernel.org/stable/c/8266ae6eafdcd5a3136592445ff4038bbc7ee80e","https://git.kernel.org/stable/c/e5c2dba62996a3a6eeb34bd248b90fc69c5a6a1b","https://git.kernel.org/stable/c/f7fb5dda555344529ce584ff7a28b109528d2f1b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50167 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: be2net: fix potential memory leak in be_xmit() The be_xmit() returns NETDEV_TX_OK without freeing skb in case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it. | ["https://git.kernel.org/stable/c/4c5f170ef4f85731a4d43ad9a6ac51106c0946be","https://git.kernel.org/stable/c/641c1beed52bf3c6deb0193fe4d38ec9ff75d2ae","https://git.kernel.org/stable/c/6b7ce8ee01c33c380aaa5077ff25215492e7eb0e","https://git.kernel.org/stable/c/77bc881d370e850b7f3cd2b5eae67d596b40efbc","https://git.kernel.org/stable/c/919ab6e2370289a2748780f44a43333cd3878aa7","https://git.kernel.org/stable/c/941026023c256939943a47d1c66671526befbb26","https://git.kernel.org/stable/c/e4dd8bfe0f6a23acd305f9b892c00899089bd621","https://git.kernel.org/stable/c/e86a79b804e26e3b7f1e415b22a085c0bb7ea3d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50184 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. | ["https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed","https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36","https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f","https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4","https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a","https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4","https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50185 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type. | ["https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5","https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25","https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb","https://git.kernel.org/stable/c/b8be15d1ae7ea4eedd547c3b3141f592fbddcd30","https://git.kernel.org/stable/c/e32d262c89e2b22cb0640223f953b548617ed8a6","https://git.kernel.org/stable/c/fde99e972b8f88cebe619241d7aa43d288ef666a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50194 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | ["https://git.kernel.org/stable/c/13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7","https://git.kernel.org/stable/c/14841bb7a531b96e2dde37423a3b33e75147c60d","https://git.kernel.org/stable/c/3d2530c65be04e93720e30f191a7cf1a3aa8b51c","https://git.kernel.org/stable/c/8165bf83b8a64be801d59cd2532b0d1ffed74d00","https://git.kernel.org/stable/c/b6a638cb600e13f94b5464724eaa6ab7f3349ca2","https://git.kernel.org/stable/c/cf60d19d40184e43d9a624e55a0da73be09e938d","https://git.kernel.org/stable/c/cf9ddf9ed94c15564a05bbf6e9f18dffa0c7df80","https://git.kernel.org/stable/c/e6ab336213918575124d6db43dc5d3554526242e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50195 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. | ["https://git.kernel.org/stable/c/1ff7247101af723731ea42ed565d54fb8f341264","https://git.kernel.org/stable/c/27abbde44b6e71ee3891de13e1a228aa7ce95bfe","https://git.kernel.org/stable/c/29f085345cde24566efb751f39e5d367c381c584","https://git.kernel.org/stable/c/673a1c5a2998acbd429d6286e6cad10f17f4f073","https://git.kernel.org/stable/c/a3f169e398215e71361774d13bf91a0101283ac2","https://git.kernel.org/stable/c/c8789fbe2bbf75845e45302cba6ffa44e1884d01","https://git.kernel.org/stable/c/d8794ac20a299b647ba9958f6d657051fc51a540","https://git.kernel.org/stable/c/e0c966bd3e31911b57ef76cec4c5796ebd88e512"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50198 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. | ["https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a","https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2","https://git.kernel.org/stable/c/905166531831beb067fffe2bdfc98031ffe89087","https://git.kernel.org/stable/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361","https://git.kernel.org/stable/c/bf3ab8e1c28f10df0823d4ff312f83c952b06a15","https://git.kernel.org/stable/c/c7c44e57750c31de43906d97813273fdffcf7d02"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50201 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) | ["https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d","https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d029908599611","https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9","https://git.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e","https://git.kernel.org/stable/c/df75c78bfeff99f9b4815c3e79e2b1b1e34fe264","https://git.kernel.org/stable/c/fda5dc80121b12871dc343ab37e0c3f0d138825d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50202 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. | ["https://git.kernel.org/stable/c/08cfa12adf888db98879dbd735bc741360a34168","https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989","https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a","https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475","https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81","https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39","https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3","https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe16916e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50205 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3","https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3","https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291","https://git.kernel.org/stable/c/72cafe63b35d06b5cfbaf807e90ae657907858da","https://git.kernel.org/stable/c/7d4eb9e22131ec154e638cbd56629195c9bcbe9a","https://git.kernel.org/stable/c/d2826873db70a6719cdd9212a6739f3e6234cfc4","https://git.kernel.org/stable/c/d575414361630b8b0523912532fcd7c79e43468c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53112 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'. | ["https://git.kernel.org/stable/c/0e04746db2ec4aec04cef5763b9d9aa32829ae2f","https://git.kernel.org/stable/c/28d4ed71ae0b4baedca3e85ee6d8f227ec75ebf6","https://git.kernel.org/stable/c/5ae8cc0b0c027e9cab22596049bc4dd1cbc37ee4","https://git.kernel.org/stable/c/620d22598110b0d0cb97a3fcca65fc473ea86e73","https://git.kernel.org/stable/c/737f34137844d6572ab7d473c998c7f977ff30eb","https://git.kernel.org/stable/c/843dfc804af4b338ead42331dd58081b428ecdf8","https://git.kernel.org/stable/c/ac0cfe8ac35cf1be54131b90d114087b558777ca","https://git.kernel.org/stable/c/b751c50e19d66cfb7360c0b55cf17b0722252d12"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53119 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmem_cache_alloc_noprof+0x2c1/0x360 [<ffffffff81d27aa0>] sk_prot_alloc+0x30/0x120 [<ffffffff81d2b54c>] sk_alloc+0x2c/0x4b0 [<ffffffff81fe049a>] __vsock_create.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtio_transport_recv_pkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsock_loopback_work+0xfd/0x140 [<ffffffff810fc6ac>] process_one_work+0x20c/0x570 [<ffffffff810fce3f>] worker_thread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] ret_from_fork+0x2d/0x50 [<ffffffff8100785a>] ret_from_fork_asm+0x1a/0x30 | ["https://git.kernel.org/stable/c/2415345042245de7601dcc6eafdbe3a3dcc9e379","https://git.kernel.org/stable/c/4310902c766e371359e6c6311056ae80b5beeac9","https://git.kernel.org/stable/c/897617a413e0bf1c6380e3b34b2f28f450508549","https://git.kernel.org/stable/c/946c7600fa2207cc8d3fbc86a518ec56f98a5813","https://git.kernel.org/stable/c/d7b0ff5a866724c3ad21f2628c22a63336deec3f","https://git.kernel.org/stable/c/e26fa236758e8baa61a82cfd9fd4388d2e8d6a4c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53130 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the "uptodate" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag. | ["https://git.kernel.org/stable/c/0a5014ad37c77ac6a2c525137c00a0e1724f6020","https://git.kernel.org/stable/c/0ce59fb1c73fdd5b6028226aeb46259a0cdc0957","https://git.kernel.org/stable/c/2026559a6c4ce34db117d2db8f710fe2a9420d5a","https://git.kernel.org/stable/c/7af3309c7a2ef26831a67125b11c34a7e01c1b2a","https://git.kernel.org/stable/c/86b19031dbc79abc378dfae357f6ea33ebeb0c95","https://git.kernel.org/stable/c/b0e4765740040c44039282057ecacd7435d1d2ba","https://git.kernel.org/stable/c/d904e4d845aafbcfd8a40c1df7d999f02f062be8","https://git.kernel.org/stable/c/ffc440a76a0f476a7e6ea838ec0dc8e9979944d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53138 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")). | ["https://git.kernel.org/stable/c/2723e8b2cbd486cb96e5a61b22473f7fd62e18df","https://git.kernel.org/stable/c/69fbd07f17b0fdaf8970bc705f5bf115c297839d","https://git.kernel.org/stable/c/93a14620b97c911489a5b008782f3d9b0c4aeff4","https://git.kernel.org/stable/c/a0ddb20a748b122ea86003485f7992fa5e84cc95","https://git.kernel.org/stable/c/c7b97f9e794d8e2bbaa50e1d6c230196fd214b5e","https://git.kernel.org/stable/c/dd6e972cc5890d91d6749bb48e3912721c4e4b25","https://git.kernel.org/stable/c/ffad2ac8c859c1c1a981fe9c4f7ff925db684a43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53140 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. | ["https://git.kernel.org/stable/c/114a61d8d94ae3a43b82446cf737fd757021b834","https://git.kernel.org/stable/c/176c41b3ca9281a9736b67c6121b03dbf0c8c08f","https://git.kernel.org/stable/c/1904fb9ebf911441f90a68e96b22aa73e4410505","https://git.kernel.org/stable/c/4e87a52133284afbd40fb522dbf96e258af52a98","https://git.kernel.org/stable/c/598c956b62699c3753929602560d8df322e60559","https://git.kernel.org/stable/c/6e3f2c512d2b7dbd247485b1dd9e43e4210a18f4","https://git.kernel.org/stable/c/bbc769d2fa1b8b368c5fbe013b5b096afa3c05ca","https://git.kernel.org/stable/c/d2fab3d66cc16cfb9e3ea1772abe6b79b71fa603"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58011 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: platform/x86: int3472: Check for adev == NULL Not all devices have an ACPI companion fwnode, so adev might be NULL. This can e.g. (theoretically) happen when a user manually binds one of the int3472 drivers to another i2c/platform device through sysfs. Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). | ["https://git.kernel.org/stable/c/0a30353beca2693d30bde477024d755ffecea514","https://git.kernel.org/stable/c/4f8b210823cc2d1f9d967f089a6c00d025bb237f","https://git.kernel.org/stable/c/a808ecf878ad646ebc9c83d9fc4ce72fd9c49d3d","https://git.kernel.org/stable/c/cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c","https://git.kernel.org/stable/c/f9c7cc44758f4930b41285a6d54afa8cbd9762b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46819 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: the warning dereferencing obj for nbio_v7_4 if ras_manager obj null, don't print NBIO err data | ["https://git.kernel.org/stable/c/130c2dc75c8c40acc3c96ededea6af80e03c14b8","https://git.kernel.org/stable/c/614564a5b28983de53b23a358ebe6c483a2aa21e","https://git.kernel.org/stable/c/70e8ec21fcb8c51446899d3bfe416b31adfa3661","https://git.kernel.org/stable/c/7d265772e44d403071a2b573eac0db60250b1c21","https://git.kernel.org/stable/c/d04ded1e73f1dcf19a71ec8b9cda3faa7acd8828","https://git.kernel.org/stable/c/d190b459b2a4304307c3468ed97477b808381011"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50141 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context PRMT needs to find the correct type of block to translate the PA-VA mapping for EFI runtime services. The issue arises because the PRMT is finding a block of type EFI_CONVENTIONAL_MEMORY, which is not appropriate for runtime services as described in Section 2.2.2 (Runtime Services) of the UEFI Specification [1]. Since the PRM handler is a type of runtime service, this causes an exception when the PRM handler is called. [Firmware Bug]: Unable to handle paging request in EFI runtime service WARNING: CPU: 22 PID: 4330 at drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0x11c/0x170 Call trace: Let PRMT find a block with EFI_MEMORY_RUNTIME for PRM handler and PRM context. If no suitable block is found, a warning message will be printed, but the procedure continues to manage the next PRM handler. However, if the PRM handler is actually called without proper allocation, it would result in a failure during error handling. By using the correct memory types for runtime services, ensure that the PRM handler and the context are properly mapped in the virtual address space during runtime, preventing the paging request error. The issue is really that only memory that has been remapped for runtime by the firmware can be used by the PRM handler, and so the region needs to have the EFI_MEMORY_RUNTIME attribute. [ rjw: Subject and changelog edits ] | ["https://git.kernel.org/stable/c/088984c8d54c0053fc4ae606981291d741c5924b","https://git.kernel.org/stable/c/20e9fafb8bb6f545667d7916b0e81e68c0748810","https://git.kernel.org/stable/c/795b080d9aa127215a5baf088a22fa09341a0126","https://git.kernel.org/stable/c/8ce081ad842510f0e70fa6065a401660eac876d4","https://git.kernel.org/stable/c/8df52929530839e878e6912e33348b54101e3250"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50258 | Medium | N/A | In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size. | ["https://git.kernel.org/stable/c/90c8482a5d9791259ba77bfdc1849fc5128b4be7","https://git.kernel.org/stable/c/9ab5cf19fb0e4680f95e506d6c544259bf1111c4","https://git.kernel.org/stable/c/ac5977001eee7660c643f8e07a2de9001990b7b8","https://git.kernel.org/stable/c/e72fd1389a5364bc6aa6312ecf30bdb5891b9486","https://git.kernel.org/stable/c/e9365368b483328639c03fc730448dccd5a25b6b"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53113 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") and commit df76cee6bbeb ("mm, page_alloc: remove redundant checks from alloc fastpath"). To fix it, check NULL pointer for preferred_zoneref->zone. | ["https://git.kernel.org/stable/c/31502374627ba9ec3e710dbd0bb00457cc6d2c19","https://git.kernel.org/stable/c/6addb2d9501ec866d7b3a3b4e665307c437e9be2","https://git.kernel.org/stable/c/8ce41b0f9d77cca074df25afd39b86e2ee3aa68e","https://git.kernel.org/stable/c/903d896448c2e50e8652aaba529a30d4d1eaa0e5","https://git.kernel.org/stable/c/d0f16cec79774c3132df006cf771eddd89d08f58"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53120 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | ["https://git.kernel.org/stable/c/06dc488a593020bd2f006798557d2a32104d8359","https://git.kernel.org/stable/c/0c7c70ff8b696cfedba350411dca736361ef9a0f","https://git.kernel.org/stable/c/6030f8bd7902e9e276a0edc09bf11979e4e2bc2e","https://git.kernel.org/stable/c/882f392d9e3649557e71efd78ae20c86039ffb7c","https://git.kernel.org/stable/c/e99c6873229fe0482e7ceb7d5600e32d623ed9d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35898 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get() nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable(). And thhere is not any protection when iterate over nf_tables_flowtables list in __nft_flowtable_type_get(). Therefore, there is pertential data-race of nf_tables_flowtables list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller nft_flowtable_type_get() to protect the entire type query process. | ["https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304","https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8","https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007","https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df","https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331","https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b","https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77","https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859","https://git.kernel.org/stable/c/24225011d81b471acc0e1e315b7d9905459a6304","https://git.kernel.org/stable/c/2485bcfe05ee3cf9ca8923a94fa2e456924c79c8","https://git.kernel.org/stable/c/69d1fe14a680042ec913f22196b58e2c8ff1b007","https://git.kernel.org/stable/c/8b891153b2e4dc0ca9d9dab8f619d49c740813df","https://git.kernel.org/stable/c/940d41caa71f0d3a52df2fde5fada524a993e331","https://git.kernel.org/stable/c/9b5b7708ec2be21dd7ef8ca0e3abe4ae9f3b083b","https://git.kernel.org/stable/c/a347bc8e6251eaee4b619da28020641eb5b0dd77","https://git.kernel.org/stable/c/e684b1674fd1ca4361812a491242ae871d6b2859","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49949 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 ("net: be more gentle about silly gso requests coming from user") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: count transport header in UFO") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WB Code starting with the faulting instruction =========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated--- | ["https://git.kernel.org/stable/c/1598d70ad9c7d0a4d9d54b82094e9f45908fda6d","https://git.kernel.org/stable/c/25ab0b87dbd89cecef8a9c60a02bb97832e471d1","https://git.kernel.org/stable/c/81fd007dcd47c34471766249853e4d4bce8eea4b","https://git.kernel.org/stable/c/939c88cbdc668dadd8cfa7a35d9066331239041c","https://git.kernel.org/stable/c/ba26060a29d3ca1bfc737aa79f7125128f35147c","https://git.kernel.org/stable/c/c20029db28399ecc50e556964eaba75c43b1e2f1","https://git.kernel.org/stable/c/d6114993e0a89fde84a60a60a8329a571580b174","https://git.kernel.org/stable/c/d70ca7598943572d5e384227bd268acb5109bf72","https://git.kernel.org/stable/c/f959cce8a2a04ce776aa8b78e83ce339e0d7fbac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49856 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will. | ["https://git.kernel.org/stable/c/0f89fb4042c08fd143bfc28af08bf6c8a0197eea","https://git.kernel.org/stable/c/20c96d0aaabfe361fc2a11c173968dc67feadbbf","https://git.kernel.org/stable/c/40fb64257dab507d86b5f1f2a62f3669ef0c91a8","https://git.kernel.org/stable/c/8132510c915815e6b537ab937d94ed66893bc7b8","https://git.kernel.org/stable/c/9c936844010466535bd46ea4ce4656ef17653644","https://git.kernel.org/stable/c/fb2d057539eda67ec7cfc369bf587e6518a9b99d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46829 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ] | ["https://git.kernel.org/stable/c/1401da1486dc1cdbef6025fd74a3977df3a3e5d0","https://git.kernel.org/stable/c/432efdbe7da5ecfcbc0c2180cfdbab1441752a38","https://git.kernel.org/stable/c/6a976e9a47e8e5b326de671811561cab12e6fb1f","https://git.kernel.org/stable/c/85f03ca98e07cd0786738b56ae73740bce0ac27f","https://git.kernel.org/stable/c/93f44655472d9cd418293d328f9d141ca234ad83","https://git.kernel.org/stable/c/a92d81c9efec9280681c27a2c0a963fd0f1338e0","https://git.kernel.org/stable/c/d33d26036a0274b472299d7dcdaa5fb34329f91b","https://git.kernel.org/stable/c/f13b5afc5c4889569d84c3011ce449f61fccfb28"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46727 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add otg_master NULL check within resource_log_pipe_topology_update [Why] Coverity reports NULL_RETURN warning. [How] Add otg_master NULL check. | ["https://git.kernel.org/stable/c/871cd9d881fa791d3f82885000713de07041c0ae","https://git.kernel.org/stable/c/aad4d3d3d3b6a362bf5db11e1f28c4a60620900d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46730 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Ensure array index tg_inst won't be -1 [WHY & HOW] tg_inst will be a negative if timing_generator_count equals 0, which should be checked before used. This fixes 2 OVERRUN issues reported by Coverity. | ["https://git.kernel.org/stable/c/687fe329f18ab0ab0496b20ed2cb003d4879d931","https://git.kernel.org/stable/c/a64284b9e1999ad5580debced4bc6d6adb28aad4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46775 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Validate function returns [WHAT & HOW] Function return values must be checked before data can be used in subsequent functions. This fixes 4 CHECKED_RETURN issues reported by Coverity. | ["https://git.kernel.org/stable/c/5639a3048c7079803256374204ad55ec52cd0b49","https://git.kernel.org/stable/c/673f816b9e1e92d1f70e1bf5f21b531e0ff9ad6c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46778 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check UnboundedRequestEnabled's value CalculateSwathAndDETConfiguration_params_st's UnboundedRequestEnabled is a pointer (i.e. dml_bool_t *UnboundedRequestEnabled), and thus if (p->UnboundedRequestEnabled) checks its address, not bool value. This fixes 1 REVERSE_INULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/4e2b49a85e7974d21364798c5d4aa8070aa864d9","https://git.kernel.org/stable/c/a7b38c7852093385d0605aa3c8a2efd6edd1edfd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46834 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ethtool: fail closed if we can't get max channel used in indirection tables Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory. Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change. | ["https://git.kernel.org/stable/c/101737d8b88dbd4be6010bac398fe810f1950036","https://git.kernel.org/stable/c/2899d58462ba868287d6ff3acad3675e7adf934f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46842 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_info The MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and the routine unconditionally frees submitted mailbox commands regardless of return status. The issue is that for MBX_TIMEOUT cases, when firmware returns SFP information at a later time, that same mailbox memory region references previously freed memory in its cmpl routine. Fix by adding checks for the MBX_TIMEOUT return code. During mailbox resource cleanup, check the mbox flag to make sure that the wait did not timeout. If the MBOX_WAKE flag is not set, then do not free the resources because it will be freed when firmware completes the mailbox at a later time in its cmpl routine. Also, increase the timeout from 30 to 60 seconds to accommodate boot scripts requiring longer timeouts. | ["https://git.kernel.org/stable/c/bba47fe3b038cca3d3ebd799665ce69d6d273b58","https://git.kernel.org/stable/c/ede596b1434b57c0b3fd5c02b326efe5c54f6e48"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-lnl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required. | ["https://git.kernel.org/stable/c/8eb57389d8ad91c67bf844f5aae4caef74b9091b","https://git.kernel.org/stable/c/c4246f1fe9f24f8dcd97887ed67d8fcfd91f4796"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53089 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [<ffff80000235eb70>] kvm_restore_timer+0x50/0x1a0 [kvm] [<ffff8000023616c8>] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [<ffff80000234c2d4>] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [<ffff800002354c70>] kvm_vcpu_block+0x70/0x120 [kvm] [<ffff800002354d80>] kvm_vcpu_halt+0x60/0x3e0 [kvm] [<ffff80000235b194>] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [<ffff80000235f548>] kvm_handle_exit+0x1c8/0x260 [kvm] | ["https://git.kernel.org/stable/c/1e4c384a4be9ed1e069e24f388ab2ee9951b77b5","https://git.kernel.org/stable/c/73adbd92f3223dc0c3506822b71c6b259d5d537b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56650 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: fix LED ID check in led_tg_check() Syzbot has reported the following BUG detected by KASAN: BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dump_stack_lvl+0x241/0x360 ? __pfx_dump_stack_lvl+0x10/0x10 ? __pfx__printk+0x10/0x10 ? _printk+0xd5/0x120 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 print_report+0x169/0x550 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x183/0x530 ? __virt_addr_valid+0x45f/0x530 ? __phys_addr+0xba/0x170 ? strlen+0x58/0x70 kasan_report+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 led_tg_check+0x18b/0x3c0 xt_check_target+0x3bb/0xa40 ? __pfx_xt_check_target+0x10/0x10 ? stack_depot_save_flags+0x6e4/0x830 ? nft_target_init+0x174/0xc30 nft_target_init+0x82d/0xc30 ? __pfx_nft_target_init+0x10/0x10 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? rcu_is_watching+0x15/0xb0 ? nf_tables_newrule+0x1609/0x2980 ? nf_tables_newrule+0x1609/0x2980 ? __kmalloc_noprof+0x21a/0x400 nf_tables_newrule+0x1860/0x2980 ? __pfx_nf_tables_newrule+0x10/0x10 ? __nla_parse+0x40/0x60 nfnetlink_rcv+0x14e5/0x2ab0 ? __pfx_validate_chain+0x10/0x10 ? __pfx_nfnetlink_rcv+0x10/0x10 ? __lock_acquire+0x1384/0x2050 ? netlink_deliver_tap+0x2e/0x1b0 ? __pfx_lock_release+0x10/0x10 ? netlink_deliver_tap+0x2e/0x1b0 netlink_unicast+0x7f8/0x990 ? __pfx_netlink_unicast+0x10/0x10 ? __virt_addr_valid+0x183/0x530 ? __check_object_size+0x48e/0x900 netlink_sendmsg+0x8e4/0xcb0 ? __pfx_netlink_sendmsg+0x10/0x10 ? aa_sock_msg_perm+0x91/0x160 ? __pfx_netlink_sendmsg+0x10/0x10 __sock_sendmsg+0x223/0x270 ____sys_sendmsg+0x52a/0x7e0 ? __pfx_____sys_sendmsg+0x10/0x10 __sys_sendmsg+0x292/0x380 ? __pfx___sys_sendmsg+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? exc_page_fault+0x590/0x8c0 ? do_syscall_64+0xb6/0x230 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... </TASK> Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further. | ["https://git.kernel.org/stable/c/04317f4eb2aad312ad85c1a17ad81fe75f1f9bc7","https://git.kernel.org/stable/c/147a42bb02de8735cb08476be6d0917987d022c2","https://git.kernel.org/stable/c/36a9d94dac28beef6b8abba46ba8874320d3e800","https://git.kernel.org/stable/c/a9bcc0b70d9baf3ff005874489a0dc9d023b54c3","https://git.kernel.org/stable/c/ab9916321c95f5280b72b4c5055e269f98627efe","https://git.kernel.org/stable/c/ad28612ebae1fcc1104bd432e99e99d87f6bfe09","https://git.kernel.org/stable/c/c40c96d98e536fc1daaa125c2332b988615e30a4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1651 | High | fixed |
|
A memory leak flaw was found in the Linux kernel in acrn_dev_ioctl in the drivers/virt/acrn/hsm.c function in how the ACRN Device Model emulates virtual NICs in VM. This flaw allows a local privileged attacker to leak unauthorized kernel information, causing a denial of service. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b","https://security.netapp.com/advisory/ntap-20220901-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecd1735f14d6ac868ae5d8b7a2bf193fa11f388b","https://security.netapp.com/advisory/ntap-20220901-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6536 | High | fixed |
|
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6536","https://bugzilla.redhat.com/show_bug.cgi?id=2254052","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6536","https://bugzilla.redhat.com/show_bug.cgi?id=2254052","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2019-3819 | Medium | N/A | A flaw was found in the Linux kernel in the function hid_debug_events_read() in drivers/hid/hid-debug.c file which may enter an infinite loop with certain parameters passed from a userspace. A local privileged user ("root") can cause a system lock up and a denial of service. Versions from v4.18 and newer are vulnerable. | ["http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00052.html","http://www.securityfocus.com/bid/106730","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3819","https://lists.debian.org/debian-lts-announce/2019/03/msg00034.html","https://lists.debian.org/debian-lts-announce/2019/04/msg00004.html","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://usn.ubuntu.com/3932-1/","https://usn.ubuntu.com/3932-2/","https://usn.ubuntu.com/4115-1/","https://usn.ubuntu.com/4118-1/","http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00052.html","http://www.securityfocus.com/bid/106730","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3819","https://lists.debian.org/debian-lts-announce/2019/03/msg00034.html","https://lists.debian.org/debian-lts-announce/2019/04/msg00004.html","https://lists.debian.org/debian-lts-announce/2019/05/msg00002.html","https://usn.ubuntu.com/3932-1/","https://usn.ubuntu.com/3932-2/","https://usn.ubuntu.com/4115-1/","https://usn.ubuntu.com/4118-1/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0500 | High | fixed |
|
A flaw was found in unrestricted eBPF usage by the BPF_BTF_LOAD, leading to a possible out-of-bounds memory write in the Linux kernel’s BPF subsystem due to the way a user loads BTF. This flaw allows a local user to crash or escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2044578","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57","https://security.netapp.com/advisory/ntap-20220519-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=2044578","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20b2aff4bc15bda809f994761d5719827d66c0b4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=216e3cd2f28dbbf1fe86848e0e29e6693b9f0a20","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34d3a78c681e8e7844b43d1a2f4671a04249c821","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c4807322660d4290ac9062c034aed6b87243861","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=48946bd6a5d695c50b34546864b79c1f910a33c1","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c25b2ae136039ffa820c26138ed4a5e5f3ab3841","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cf9f2f8d62eca810afbd1ee6cc0800202b000e57","https://security.netapp.com/advisory/ntap-20220519-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52896 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between quota rescan and disable leading to NULL pointer deref If we have one task trying to start the quota rescan worker while another one is trying to disable quotas, we can end up hitting a race that results in the quota rescan worker doing a NULL pointer dereference. The steps for this are the following: 1) Quotas are enabled; 2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan(). It calls qgroup_rescan_init() which returns 0 (success) and then joins a transaction and commits it; 3) Task B calls the quota disable ioctl and enters btrfs_quota_disable(). It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info->flags and calls btrfs_qgroup_wait_for_completion(), which returns immediately since the rescan worker is not yet running. Then it starts a transaction and locks fs_info->qgroup_ioctl_lock; 4) Task A queues the rescan worker, by calling btrfs_queue_work(); 5) The rescan worker starts, and calls rescan_should_stop() at the start of its while loop, which results in 0 iterations of the loop, since the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info->flags by task B at step 3); 6) Task B sets fs_info->quota_root to NULL; 7) The rescan worker tries to start a transaction and uses fs_info->quota_root as the root argument for btrfs_start_transaction(). This results in a NULL pointer dereference down the call chain of btrfs_start_transaction(). The stack trace is something like the one reported in Link tag below: general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f] CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: btrfs-qgroup-rescan btrfs_work_helper RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564 Code: 48 89 fb 48 (...) RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206 RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402 btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> Modules linked in: So fix this by having the rescan worker function not attempt to start a transaction if it didn't do any rescan work. | ["https://git.kernel.org/stable/c/1004fc90f0d79a4b7d9e3d432729914f472f9ad1","https://git.kernel.org/stable/c/3bd43374857103ba3cac751d6d4afa8d83b5d92a","https://git.kernel.org/stable/c/64287cd456a22373053998c1fccf14b651e9cbbd","https://git.kernel.org/stable/c/89ac597e3e807b91e2ebd6a7c36fec7b97290233","https://git.kernel.org/stable/c/b7adbf9ada3513d2092362c8eac5cddc5b651f5c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50082 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait(). | ["https://git.kernel.org/stable/c/04f283fc16c8d5db641b6bffd2d8310aa7eccebc","https://git.kernel.org/stable/c/3bc6d0f8b70a9101456cf02ab99acb75254e1852","https://git.kernel.org/stable/c/455a469758e57a6fe070e3e342db12e4a629e0eb","https://git.kernel.org/stable/c/4c5b123ab289767afe940389dbb963c5c05e594e","https://git.kernel.org/stable/c/b5e900a3612b69423a0e1b0ab67841a1fb4af80f","https://git.kernel.org/stable/c/d04b72c9ef2b0689bfc1057d21c4aeed087c329f","https://git.kernel.org/stable/c/e972b08b91ef48488bae9789f03cfedb148667fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52434 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential OOBs in smb2_parse_contexts() Validate offsets and lengths before dereferencing create contexts in smb2_parse_contexts(). This fixes following oops when accessing invalid create contexts from server: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e | ["https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5","https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa","https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29","https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb","https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48","https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144","https://git.kernel.org/stable/c/13fb0fc4917621f3dfa285a27eaf7151d770b5e5","https://git.kernel.org/stable/c/17a0f64cc02d4972e21c733d9f21d1c512963afa","https://git.kernel.org/stable/c/1ae3c59355dc9882e09c020afe8ffbd895ad0f29","https://git.kernel.org/stable/c/6726429c18c62dbf5e96ebbd522f262e016553fb","https://git.kernel.org/stable/c/890bc4fac3c0973a49cac35f634579bebba7fe48","https://git.kernel.org/stable/c/af1689a9b7701d9907dfc84d2a4b57c4bc907144","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20250117-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46765 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: protect XDP configuration with a mutex The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler. XDP setup and PF reset code access the same resources in the following sections: * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked * ice_vsi_rebuild() for the PF VSI - not protected * ice_vsi_open() - already rtnl-locked With an unfortunate timing, such accesses can result in a crash such as the one below: [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: error_code(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice ice_service_task [ice] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice] [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice] [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice] [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice] [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice] [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice] [ +0.000145] ice_rebuild+0x18c/0x840 [ice] [ +0.000145] ? delay_tsc+0x4a/0xc0 [ +0.000022] ? delay_tsc+0x92/0xc0 [ +0.000020] ice_do_reset+0x140/0x180 [ice] [ +0.000886] ice_service_task+0x404/0x1030 [ice] [ +0.000824] process_one_work+0x171/0x340 [ +0.000685] worker_thread+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? __pfx_worker_thread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? __pfx_kthread+0x10/0x10 [ +0.000616] ret_from_fork+0x2d/0x50 [ +0.000612] ? __pfx_kthread+0x10/0x10 [ +0.000604] ret_from_fork_asm+0x1b/0x30 [ +0.000604] </TASK> The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway. There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect ice_vsi_rebuild() with rtnl_lock(). Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp(). Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open The latter case is actually already handled through !netif_running() case, we just need to adjust flag checking a little. The former one is not as trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion. Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to indicate that ice_x ---truncated--- | ["https://git.kernel.org/stable/c/2504b8405768a57a71e660dbfd5abd59f679a03f","https://git.kernel.org/stable/c/2f057db2fb29bc209c103050647562e60554d3d3","https://git.kernel.org/stable/c/391f7dae3d836891fc6cfbde38add2d0e10c6b7f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: avoid holding freeze_mutex during mmap operation We use map->freeze_mutex to prevent races between map_freeze() and memory mapping BPF map contents with writable permissions. The way we naively do this means we'll hold freeze_mutex for entire duration of all the mm and VMA manipulations, which is completely unnecessary. This can potentially also lead to deadlocks, as reported by syzbot in [0]. So, instead, hold freeze_mutex only during writeability checks, bump (proactively) "write active" count for the map, unlock the mutex and proceed with mmap logic. And only if something went wrong during mmap logic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/ | ["https://git.kernel.org/stable/c/0d90d9e154144a3a80e9fc0eb9b21b7fc990f68f","https://git.kernel.org/stable/c/271e49f8a58edba65bc2b1250a0abaa98c4bfdbe","https://git.kernel.org/stable/c/29cfda62ab4d92ab94123813db49ab76c1e61b29","https://git.kernel.org/stable/c/2ce31c97c219b4fe797749f950274f246eb88c49","https://git.kernel.org/stable/c/4759acbd44d24a69b7b14848012ec4201d6c5501","https://git.kernel.org/stable/c/bc27c52eea189e8f7492d40739b7746d67b65beb","https://git.kernel.org/stable/c/d95607a5f2f9bb08194c9deaf4a5f3e8ba59a9d4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not start relocation until in progress drops are done We hit a bug with a recovering relocation on mount for one of our file systems in production. I reproduced this locally by injecting errors into snapshot delete with balance running at the same time. This presented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: <TASK> insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 </TASK> Normally snapshot deletion and relocation are excluded from running at the same time by the fs_info->cleaner_mutex. However if we had a pending balance waiting to get the ->cleaner_mutex, and a snapshot deletion was running, and then the box crashed, we would come up in a state where we have a half deleted snapshot. Again, in the normal case the snapshot deletion needs to complete before relocation can start, but in this case relocation could very well start before the snapshot deletion completes, as we simply add the root to the dead roots list and wait for the next time the cleaner runs to clean up the snapshot. Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that had a pending drop_progress key. If they do then we know we were in the middle of the drop operation and set a flag on the fs_info. Then balance can wait until this flag is cleared to start up again. If there are DEAD_ROOT's that don't have a drop_progress set then we're safe to start balance right away as we'll be properly protected by the cleaner_mutex. | ["https://git.kernel.org/stable/c/5e70bc827b563caf22e1203428cc3719643de5aa","https://git.kernel.org/stable/c/6599d5e8bd758d897fd2ef4dc388ae50278b1f7e","https://git.kernel.org/stable/c/b4be6aefa73c9a6899ef3ba9c5faaa8a66e333ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not WARN_ON() if we have PageError set Whenever we do any extent buffer operations we call assert_eb_page_uptodate() to complain loudly if we're operating on an non-uptodate page. Our overnight tests caught this warning earlier this week WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This was partially fixed by c2e39305299f01 ("btrfs: clear extent buffer uptodate when we fail to write it"), however all that fix did was keep us from finding extent buffers after a failed writeout. It didn't keep us from continuing to use a buffer that we already had found. In this case we're searching the commit root to cache the block group, so we can start committing the transaction and switch the commit root and then start writing. After the switch we can look up an extent buffer that hasn't been written yet and start processing that block group. Then we fail to write that block out and clear Uptodate on the page, and then we start spewing these errors. Normally we're protected by the tree lock to a certain degree here. If we read a block we have that block read locked, and we block the writer from locking the block before we submit it for the write. However this isn't necessarily fool proof because the read could happen before we do the submit_bio and after we locked and unlocked the extent buffer. Also in this particular case we have path->skip_locking set, so that won't save us here. We'll simply get a block that was valid when we read it, but became invalid while we were using it. What we really want is to catch the case where we've "read" a block but it's not marked Uptodate. On read we ClearPageError(), so if we're !Uptodate and !Error we know we didn't do the right thing for reading the page. Fix this by checking !Uptodate && !Error, this way we will not complain if our buffer gets invalidated while we're using it, and we'll maintain the spirit of the check which is to make sure we have a fully in-cache block while we're messing with it. | ["https://git.kernel.org/stable/c/9efcc83b33b576302147634eca9bece8e3737e34","https://git.kernel.org/stable/c/a50e1fcbc9b85fd4e95b89a75c0884cb032a3e06","https://git.kernel.org/stable/c/e00077aa439f0e8f416699fa4e9600db6583db70"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43906 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/admgpu: fix dereferencing null pointer context When user space sets an invalid ta type, the pointer context will be empty. So it need to check the pointer context before using it | ["https://git.kernel.org/stable/c/030ffd4d43b433bc6671d9ec34fc12c59220b95d","https://git.kernel.org/stable/c/4fd52f7c2c11d330571c6bde06e5ea508ec25c9d","https://git.kernel.org/stable/c/641dac64178ccdb9e45c92b67120316896294d05"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44961 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Forward soft recovery errors to userspace As we discussed before[1], soft recovery should be forwarded to userspace, or we can get into a really bad state where apps will keep submitting hanging command buffers cascading us to a hard reset. 1: https://lore.kernel.org/all/bf23d5ed-9a6b-43e7-84ee-8cbfd0d60f18@froggi.es/ (cherry picked from commit 434967aadbbbe3ad9103cc29e9a327de20fdba01) | ["https://git.kernel.org/stable/c/0da0b06165d83a8ecbb6582d9d5a135f9d38a52a","https://git.kernel.org/stable/c/829798c789f567ef6ba4b084c15b7b5f3bd98d51","https://git.kernel.org/stable/c/c28d207edfc5679585f4e96acb67000076ce90be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44962 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Shutdown timer and prevent rearming when driver unloading When unload the btnxpuart driver, its associated timer will be deleted. If the timer happens to be modified at this moment, it leads to the kernel call this timer even after the driver unloaded, resulting in kernel panic. Use timer_shutdown_sync() instead of del_timer_sync() to prevent rearming. panic log: Internal error: Oops: 0000000086000007 [#1] PREEMPT SMP Modules linked in: algif_hash algif_skcipher af_alg moal(O) mlan(O) crct10dif_ce polyval_ce polyval_generic snd_soc_imx_card snd_soc_fsl_asoc_card snd_soc_imx_audmux mxc_jpeg_encdec v4l2_jpeg snd_soc_wm8962 snd_soc_fsl_micfil snd_soc_fsl_sai flexcan snd_soc_fsl_utils ap130x rpmsg_ctrl imx_pcm_dma can_dev rpmsg_char pwm_fan fuse [last unloaded: btnxpuart] CPU: 5 PID: 723 Comm: memtester Tainted: G O 6.6.23-lts-next-06207-g4aef2658ac28 #1 Hardware name: NXP i.MX95 19X19 board (DT) pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0xffff80007a2cf464 lr : call_timer_fn.isra.0+0x24/0x80 ... Call trace: 0xffff80007a2cf464 __run_timers+0x234/0x280 run_timer_softirq+0x20/0x40 __do_softirq+0x100/0x26c ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0xc0/0xdc el0_interrupt+0x54/0xd8 __el0_irq_handler_common+0x18/0x24 el0t_64_irq_handler+0x10/0x1c el0t_64_irq+0x190/0x194 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0,c0000000,40028143,1000721b Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]--- | ["https://git.kernel.org/stable/c/0d0df1e750bac0fdaa77940e711c1625cff08d33","https://git.kernel.org/stable/c/28bbb5011a9723700006da67bdb57ab6a914452b","https://git.kernel.org/stable/c/4d9adcb94d55e9be8a3e464d9f2ff7d27e2ed016"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42237 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: cs_dsp: Validate payload length before processing block Move the payload length check in cs_dsp_load() and cs_dsp_coeff_load() to be done before the block is processed. The check that the length of a block payload does not exceed the number of remaining bytes in the firwmware file buffer was being done near the end of the loop iteration. However, some code before that check used the length field without validating it. | ["https://git.kernel.org/stable/c/259955eca9b7acf1299b1ac077d8cfbe12df35d8","https://git.kernel.org/stable/c/3a9cd924aec1288d675df721f244da4dd7e16cff","https://git.kernel.org/stable/c/6598afa9320b6ab13041616950ca5f8f938c0cf1","https://git.kernel.org/stable/c/71d9e313d8f7e18c543a9c80506fe6b1eb1fe0c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42252 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: closures: Change BUG_ON() to WARN_ON() If a BUG_ON() can be hit in the wild, it shouldn't be a BUG_ON() For reference, this has popped up once in the CI, and we'll need more info to debug it: 03240 ------------[ cut here ]------------ 03240 kernel BUG at lib/closure.c:21! 03240 kernel BUG at lib/closure.c:21! 03240 Internal error: Oops - BUG: 00000000f2000800 [#1] SMP 03240 Modules linked in: 03240 CPU: 15 PID: 40534 Comm: kworker/u80:1 Not tainted 6.10.0-rc4-ktest-ga56da69799bd #25570 03240 Hardware name: linux,dummy-virt (DT) 03240 Workqueue: btree_update btree_interior_update_work 03240 pstate: 00001005 (nzcv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) 03240 pc : closure_put+0x224/0x2a0 03240 lr : closure_put+0x24/0x2a0 03240 sp : ffff0000d12071c0 03240 x29: ffff0000d12071c0 x28: dfff800000000000 x27: ffff0000d1207360 03240 x26: 0000000000000040 x25: 0000000000000040 x24: 0000000000000040 03240 x23: ffff0000c1f20180 x22: 0000000000000000 x21: ffff0000c1f20168 03240 x20: 0000000040000000 x19: ffff0000c1f20140 x18: 0000000000000001 03240 x17: 0000000000003aa0 x16: 0000000000003ad0 x15: 1fffe0001c326974 03240 x14: 0000000000000a1e x13: 0000000000000000 x12: 1fffe000183e402d 03240 x11: ffff6000183e402d x10: dfff800000000000 x9 : ffff6000183e402e 03240 x8 : 0000000000000001 x7 : 00009fffe7c1bfd3 x6 : ffff0000c1f2016b 03240 x5 : ffff0000c1f20168 x4 : ffff6000183e402e x3 : ffff800081391954 03240 x2 : 0000000000000001 x1 : 0000000000000000 x0 : 00000000a8000000 03240 Call trace: 03240 closure_put+0x224/0x2a0 03240 bch2_check_for_deadlock+0x910/0x1028 03240 bch2_six_check_for_deadlock+0x1c/0x30 03240 six_lock_slowpath.isra.0+0x29c/0xed0 03240 six_lock_ip_waiter+0xa8/0xf8 03240 __bch2_btree_node_lock_write+0x14c/0x298 03240 bch2_trans_lock_write+0x6d4/0xb10 03240 __bch2_trans_commit+0x135c/0x5520 03240 btree_interior_update_work+0x1248/0x1c10 03240 process_scheduled_works+0x53c/0xd90 03240 worker_thread+0x370/0x8c8 03240 kthread+0x258/0x2e8 03240 ret_from_fork+0x10/0x20 03240 Code: aa1303e0 d63f0020 a94363f7 17ffff8c (d4210000) 03240 ---[ end trace 0000000000000000 ]--- 03240 Kernel panic - not syncing: Oops - BUG: Fatal exception 03240 SMP: stopping secondary CPUs 03241 SMP: failed to stop secondary CPUs 13,15 03241 Kernel Offset: disabled 03241 CPU features: 0x00,00000003,80000008,4240500b 03241 Memory Limit: none 03241 ---[ end Kernel panic - not syncing: Oops - BUG: Fatal exception ]--- 03246 ========= FAILED TIMEOUT copygc_torture_no_checksum in 7200s | ["https://git.kernel.org/stable/c/339b84ab6b1d66900c27bd999271cb2ae40ce812","https://git.kernel.org/stable/c/5d85f2ab79d5918a66539ebf046c099f7448db8d","https://git.kernel.org/stable/c/c894a74756478bb7aec894bcc513add3d554c0cf","https://git.kernel.org/stable/c/ecb4aaa658da760fb83afd79cc5fd4360aa60635"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57977 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memcg: fix soft lockup in the OOM process A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered. watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:console_unlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintk_emit+0x193/0x280 printk+0x52/0x6e dump_task+0x114/0x130 mem_cgroup_scan_tasks+0x76/0x100 dump_header+0x1fe/0x210 oom_kill_process+0xd1/0x100 out_of_memory+0x125/0x570 mem_cgroup_out_of_memory+0xb5/0xd0 try_charge+0x720/0x770 mem_cgroup_try_charge+0x86/0x180 mem_cgroup_try_charge_delay+0x1c/0x40 do_anonymous_page+0xb5/0x390 handle_mm_fault+0xc4/0x1f0 This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process. To fix this issue, call 'cond_resched' in the 'mem_cgroup_scan_tasks' function per 1000 iterations. For global OOM, call 'touch_softlockup_watchdog' per 1000 iterations to avoid this issue. | ["https://git.kernel.org/stable/c/0a09d56e1682c951046bf15542b3e9553046c9f6","https://git.kernel.org/stable/c/110399858194c71f11afefad6e7be9e3876b284f","https://git.kernel.org/stable/c/46576834291869457d4772bb7df72d7c2bb3d57f","https://git.kernel.org/stable/c/72f2c0b7c152c2983ed51d48c3272cab4f34d965","https://git.kernel.org/stable/c/972486d37169fe85035e81b8c5dff21f70df1173","https://git.kernel.org/stable/c/a9042dbc1ed4bf25a5f5c699d10c3d676abf8ca2","https://git.kernel.org/stable/c/ade81479c7dda1ce3eedb215c78bc615bbd04f06","https://git.kernel.org/stable/c/c3a3741db8c1202aa959c77df3a4c361612d1eb1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47661 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow from uint32_t to uint8_t [WHAT & HOW] dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. | ["https://git.kernel.org/stable/c/30d1b783b6eeaf49d311a072c70d618d993d01ec","https://git.kernel.org/stable/c/d6b54900c564e35989cf6813e4071504fa0a90e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47662 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection [Why] These registers should not be read from driver and triggering the security violation when DMCUB work times out and diagnostics are collected blocks Z8 entry. [How] Remove the register read from DCN35. | ["https://git.kernel.org/stable/c/466423c6dd8af23ebb3a69d43434d01aed0db356","https://git.kernel.org/stable/c/eba4b2a38ccdf074a053834509545703d6df1d57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47683 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Skip Recompute DSC Params if no Stream on Link [why] Encounter NULL pointer dereference uner mst + dsc setup. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 [how] dsc recompute should be skipped if no mode change detected on the new request. If detected, keep checking whether the stream is already on current state or not. | ["https://git.kernel.org/stable/c/7c887efda1201110211fed8921a92a713e0b6bcd","https://git.kernel.org/stable/c/8151a6c13111b465dbabe07c19f572f7cbd16fef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity. | ["https://git.kernel.org/stable/c/4914c8bfee1843fae046a12970b6f178e6642659","https://git.kernel.org/stable/c/58a8ee96f84d2c21abb85ad8c22d2bbdf59bd7a9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49908 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() error: we previously assumed 'afb' could be null (see line 8388) | ["https://git.kernel.org/stable/c/0fe20258b4989b9112b5e9470df33a0939403fd4","https://git.kernel.org/stable/c/a742168b6a39ead257da53bcbe472384d6e14a1b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49910 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma. | ["https://git.kernel.org/stable/c/d8ee900b92b6526cf84275b49a473155ad75c70e","https://git.kernel.org/stable/c/dd340acd42c24a3f28dd22fae6bf38662334264c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49916 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225) | ["https://git.kernel.org/stable/c/4b6377f0e96085cbec96eb7f0b282430ccdd3d75","https://git.kernel.org/stable/c/ac1c41e318074d8a9ea925787e366be15d7645e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49920 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns "implies that stream_enc and dc->bw_vbios might be null". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity. | ["https://git.kernel.org/stable/c/26787fb6c2b2ee0d1a7e1574b36f4711ae40fe27","https://git.kernel.org/stable/c/fdd5ecbbff751c3b9061d8ebb08e5c96119915b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49921 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns "implies that "dc->clk_mgr" might be null". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity. | ["https://git.kernel.org/stable/c/5b35bf1a82eb29841b67ff5643ba83762250fc24","https://git.kernel.org/stable/c/be1fb44389ca3038ad2430dac4234669bc177ee3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49940 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case. | ["https://git.kernel.org/stable/c/24256415d18695b46da06c93135f5b51c548b950","https://git.kernel.org/stable/c/f7415e60c25a6108cd7955a20b2e66b6251ffe02"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49968 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting. | ["https://git.kernel.org/stable/c/985b67cd86392310d9e9326de941c22fc9340eec","https://git.kernel.org/stable/c/e1373903db6c4ac994de0d18076280ad88e12dee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49971 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity. | ["https://git.kernel.org/stable/c/6d64d39486197083497a01b39e23f2f8474b35d3","https://git.kernel.org/stable/c/e9e48b7bb9cf3b78f0305ef0144aaf61da0a83d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49972 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails. | ["https://git.kernel.org/stable/c/80345daa5746184195f2d383a2f1bad058f0f94c","https://git.kernel.org/stable/c/892abca6877a96c9123bb1c010cafccdf8ca1b75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50090 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a) | ["https://git.kernel.org/stable/c/6c10ba06bb1b48acce6d4d9c1e33beb9954f1788","https://git.kernel.org/stable/c/bcb5be3421705e682b0b32073ad627056d6bc2a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50179 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference. | ["https://git.kernel.org/stable/c/11ab19d48ab877430eed0c7d83810970bbcbc4f6","https://git.kernel.org/stable/c/126b567a2ef65fc38a71d832bf1216c56816f231","https://git.kernel.org/stable/c/74b302ebad5b43ac17460fa58092d892a3cba6eb","https://git.kernel.org/stable/c/9d4f619153bab7fa59736462967821d6521a38cb","https://git.kernel.org/stable/c/c08dfb1b49492c09cf13838c71897493ea3b424e","https://git.kernel.org/stable/c/c26c5ec832dd9e9dcd0a0a892a485c99889b68f0","https://git.kernel.org/stable/c/ea98284fc4fb05f276737d2043b02b62be5a8dfb","https://git.kernel.org/stable/c/f55e003d261baa7c57d51ae5c8ec1f5c26a35c89","https://git.kernel.org/stable/c/f863bfd0a2c6c99011c62ea71ac04f8e78707da9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49024 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: m_can: pci: add missing m_can_class_free_dev() in probe/remove methods In m_can_pci_remove() and error handling path of m_can_pci_probe(), m_can_class_free_dev() should be called to free resource allocated by m_can_class_allocate_dev(), otherwise there will be memleak. | ["https://git.kernel.org/stable/c/0bbb88651ef6b7fbb1bf75ec7ba69add632e834b","https://git.kernel.org/stable/c/1eca1d4cc21b6d0fc5f9a390339804c0afce9439","https://git.kernel.org/stable/c/ea8dc27bb044e19868155e500ce397007be98656"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47703 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned. | ["https://git.kernel.org/stable/c/1050727d83e70449991c29dd1cf29fe936a63da3","https://git.kernel.org/stable/c/27ca3e20fe80be85a92b10064dfeb56cb2564b1c","https://git.kernel.org/stable/c/5d99e198be279045e6ecefe220f5c52f8ce9bfd5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49955 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister(). | ["https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7","https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163deccdc16","https://git.kernel.org/stable/c/76fb2cbf01571926da8ecf6876cc8cb07d3f5183","https://git.kernel.org/stable/c/9f469ef1c79dac7f9ac1518643a33703918f7e13","https://git.kernel.org/stable/c/c47843a831e0eae007ad7e848d208e675ba4c132","https://git.kernel.org/stable/c/ca1fb7942a287b40659cc79551a1de54a2c2e7d5","https://git.kernel.org/stable/c/ca26e8eed9c1c6651f51f7fa38fe444f8573cd1b","https://git.kernel.org/stable/c/ce31847f109c3a5b2abdd19d7bcaafaacfde53de","https://git.kernel.org/stable/c/da964de4c18199e14b961b5b2e5e6570552a313c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56634 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: grgpio: Add NULL check in grgpio_probe devm_kasprintf() can return a NULL pointer on failure,but this returned value in grgpio_probe is not checked. Add NULL check in grgpio_probe, to handle kernel NULL pointer dereference error. | ["https://git.kernel.org/stable/c/050b23d081da0f29474de043e9538c1f7a351b3b","https://git.kernel.org/stable/c/09adf8792b61c09ae543972a1ece1884ef773848","https://git.kernel.org/stable/c/4733f68e59bb7b9e3d395699abb18366954b9ba7","https://git.kernel.org/stable/c/53ff0caa6ad57372d426b4f48fc0f66df43a731f","https://git.kernel.org/stable/c/8d2ca6ac3711a4f4015d26b7cc84f325ac608edb","https://git.kernel.org/stable/c/ad4dfa7ea7f5f7e9a3c78627cfc749bc7005ca7a","https://git.kernel.org/stable/c/db2fc255fcf41f536ac8666409849e11659af88d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46773 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check denominator pbn_div before used [WHAT & HOW] A denominator cannot be 0, and is checked before used. This fixes 1 DIVIDE_BY_ZERO issue reported by Coverity. | ["https://git.kernel.org/stable/c/116a678f3a9abc24f5c9d2525b7393d18d9eb58e","https://git.kernel.org/stable/c/11f997143c67680d6e40a13363618380cd57a414","https://git.kernel.org/stable/c/20e7164c52d9bfbb9d9862b833fa989624a61345","https://git.kernel.org/stable/c/dfafee0a7b51c7c9612edd2d991401294964d02f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46826 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ELF: fix kernel.randomize_va_space double read ELF loader uses "randomize_va_space" twice. It is sysctl and can change at any moment, so 2 loads could see 2 different values in theory with unpredictable consequences. Issue exactly one load for consistent value across one exec. | ["https://git.kernel.org/stable/c/1cf8cd80903073440b6ea055811d04edd24fe4f7","https://git.kernel.org/stable/c/1f81d51141a234ad0a3874b4d185dc27a521cd27","https://git.kernel.org/stable/c/2a97388a807b6ab5538aa8f8537b2463c6988bd2","https://git.kernel.org/stable/c/53f17409abf61f66b6f05aff795e938e5ba811d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46835 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix smatch static checker warning adev->gfx.imu.funcs could be NULL | ["https://git.kernel.org/stable/c/8bc7b3ce33e64c74211ed17aec823fc4e523426a","https://git.kernel.org/stable/c/bdbdc7cecd00305dc844a361f9883d3a21022027","https://git.kernel.org/stable/c/c2056c7a840f0dbf293bc3b0d91826d001668fb0","https://git.kernel.org/stable/c/d40c2c3dd0395fe7fdc19bd96551e87251426d66"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50248 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region. | ["https://git.kernel.org/stable/c/22cdf3be7d34f61a91b9e2966fec3a29f3871398","https://git.kernel.org/stable/c/386613a44b858304a88529ade2ccc1e079a5fc56","https://git.kernel.org/stable/c/556bdf27c2dd5c74a9caacbe524b943a6cd42d99","https://git.kernel.org/stable/c/809f9b419c75f8042c58434d2bfe849140643e9d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3545 | High | fixed |
|
A vulnerability has been found in Linux Kernel and classified as critical. Affected by this vulnerability is the function area_cache_get of the file drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211045 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20221223-0003/","https://vuldb.com/?id.211045","https://www.debian.org/security/2023/dsa-5324","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20221223-0003/","https://vuldb.com/?id.211045","https://www.debian.org/security/2023/dsa-5324"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2018-10876 | Medium | N/A | A flaw was found in Linux kernel in the ext4 filesystem code. A use-after-free is possible in ext4_ext_remove_space() function when mounting and operating a crafted ext4 image. | ["http://patchwork.ozlabs.org/patch/929239/","http://www.securityfocus.com/bid/104904","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2019:0525","https://bugzilla.kernel.org/show_bug.cgi?id=199403","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10876","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8844618d8aa7a9973e7b527d038a2a589665002c","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/","http://patchwork.ozlabs.org/patch/929239/","http://www.securityfocus.com/bid/104904","http://www.securityfocus.com/bid/106503","https://access.redhat.com/errata/RHSA-2019:0525","https://bugzilla.kernel.org/show_bug.cgi?id=199403","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-10876","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8844618d8aa7a9973e7b527d038a2a589665002c","https://lists.debian.org/debian-lts-announce/2018/07/msg00020.html","https://usn.ubuntu.com/3753-1/","https://usn.ubuntu.com/3753-2/","https://usn.ubuntu.com/3871-1/","https://usn.ubuntu.com/3871-3/","https://usn.ubuntu.com/3871-4/","https://usn.ubuntu.com/3871-5/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. | ["https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43","https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71","https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1","https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b","https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b","https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b","https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730","https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126","https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6","https://git.kernel.org/stable/c/3948abaa4e2be938ccdfc289385a27342fb13d43","https://git.kernel.org/stable/c/423b6bdf19bbc5e1f7e7461045099917378f7e71","https://git.kernel.org/stable/c/4bac28f441e3cc9d3f1a84c8d023228a68d8a7c1","https://git.kernel.org/stable/c/772a7def9868091da3bcb0d6c6ff9f0c03d7fa8b","https://git.kernel.org/stable/c/bf9ec1b24ab4e94345aa1c60811dd329f069c38b","https://git.kernel.org/stable/c/c1362eae861db28b1608b9dc23e49634fe87b63b","https://git.kernel.org/stable/c/cba138f1ef37ec6f961baeab62f312dedc7cf730","https://git.kernel.org/stable/c/cde76b3af247f615447bcfecf610bb76c3529126","https://git.kernel.org/stable/c/e6450d5e46a737a008b4885aa223486113bf0ad6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47640 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix early region not updated correctly The shadow's page table is not updated when PTE_RPN_SHIFT is 24 and PAGE_SHIFT is 12. It not only causes false positives but also false negative as shown the following text. Fix it by bringing the logic of kasan_early_shadow_page_entry here. 1. False Positive: ================================================================== BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50 Write of size 16 at addr f57f3be0 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1 Call Trace: [c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable) [c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300 [c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200 [c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0 [c80d1cc0] [c03018a4] memset+0x34/0x90 [c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50 [c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570 [c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0 [c80d1db0] [c2036580] init_sd+0xc4/0x1d0 [c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c [c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384 [c80d1ef0] [c0004b14] kernel_init+0x24/0x170 [c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64 Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== 2. False Negative (with KASAN tests): ================================================================== Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan ================================================================== After fix: ok 1 - kasan | ["https://git.kernel.org/stable/c/5a3d8f3192a409893c57808cc935e16484df1068","https://git.kernel.org/stable/c/7f19245c3647afea8c7c41f795506ef70f64b9f2","https://git.kernel.org/stable/c/dd75080aa8409ce10d50fb58981c6b59bf8707d3","https://git.kernel.org/stable/c/de56beace6648065d404cd9835aa7d30e3df519d","https://git.kernel.org/stable/c/e3d157a4b4f4e0268c98be5b7013bf4b31234bb6","https://git.kernel.org/stable/c/f39a3309393a4a484532f6ba745c6acbcfe06115"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49058 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: potential buffer overflow in handling symlinks Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. | ["https://git.kernel.org/stable/c/1316c28569a80ab3596eeab05bf5e01991e7e739","https://git.kernel.org/stable/c/22d658c6c5affed10c8907e67160cef0b6c92186","https://git.kernel.org/stable/c/3e582749e742e662a8e9bb37cffac62dccaaa1e2","https://git.kernel.org/stable/c/4e166a41180be2f1e66bbb6d46448e80a9a5ec05","https://git.kernel.org/stable/c/515e7ba11ef043d6febe69389949c8ef5f25e9d0","https://git.kernel.org/stable/c/64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304","https://git.kernel.org/stable/c/9901b07ba42b39266b34a888e48d7306fd707bee","https://git.kernel.org/stable/c/eb5f51756944735ac70cd8bb38637cc202e29c91"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49087 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rxrpc: fix a race in rxrpc_exit_net() Current code can lead to the following race: CPU0 CPU1 rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work); rxrpc_exit_net() exits while peer_keepalive_timer is still armed, leading to use-after-free. syzbot report was: ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0 WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanup_net RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK> | ["https://git.kernel.org/stable/c/08ff0e74fab517dbc44e11b8bc683dd4ecc65950","https://git.kernel.org/stable/c/1946014ca3b19be9e485e780e862c375c6f98bad","https://git.kernel.org/stable/c/41024a40f6c793abbb916a857f18fb009f07464c","https://git.kernel.org/stable/c/571d8e1d154ca18f08dcb72b69318d36e10010a0","https://git.kernel.org/stable/c/7ee84d29f22de6f6c63fad6c54690517659862f1","https://git.kernel.org/stable/c/864297ee30727ae6233f80296b7fc91442620b05","https://git.kernel.org/stable/c/cd8aef1f30d1215648e4e6686cfb422004851429"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49176 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bfq: fix use-after-free in bfq_dispatch_request KASAN reports a use-after-free report when doing normal scsi-mq test [69832.239032] ================================================================== [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0 [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155 [69832.244656] [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8 [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [69832.249069] Workqueue: kblockd blk_mq_run_work_fn [69832.250022] Call Trace: [69832.250541] dump_stack+0x9b/0xce [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0 [69832.252243] print_address_description.constprop.6+0x3e/0x60 [69832.253381] ? __cpuidle_text_end+0x5/0x5 [69832.254211] ? vprintk_func+0x6b/0x120 [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0 [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0 [69832.256914] kasan_report.cold.9+0x22/0x3a [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0 [69832.258755] check_memory_region+0x1c1/0x1e0 [69832.260248] bfq_dispatch_request+0x1045/0x44b0 [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440 [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170 [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100 [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570 [69832.267147] ? __switch_to+0x5f4/0xee0 [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270 [69832.269840] blk_mq_run_work_fn+0x51/0x60 [69832.278170] process_one_work+0x6d4/0xfe0 [69832.278984] worker_thread+0x91/0xc80 [69832.279726] ? __kthread_parkme+0xb0/0x110 [69832.280554] ? process_one_work+0xfe0/0xfe0 [69832.281414] kthread+0x32d/0x3f0 [69832.282082] ? kthread_park+0x170/0x170 [69832.282849] ret_from_fork+0x1f/0x30 [69832.283573] [69832.283886] Allocated by task 7725: [69832.284599] kasan_save_stack+0x19/0x40 [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0 [69832.286350] kmem_cache_alloc_node+0x13f/0x460 [69832.287237] bfq_get_queue+0x3d4/0x1140 [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510 [69832.289015] bfq_init_rq+0x337/0x2d50 [69832.289749] bfq_insert_requests+0x304/0x4e10 [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390 [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760 [69832.292538] blk_flush_plug_list+0x2c5/0x480 [69832.293392] io_schedule_prepare+0xb2/0xd0 [69832.294209] io_schedule_timeout+0x13/0x80 [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270 [69832.296137] submit_bio_wait+0x103/0x1a0 [69832.296932] blkdev_issue_discard+0xe6/0x160 [69832.297794] blk_ioctl_discard+0x219/0x290 [69832.298614] blkdev_common_ioctl+0x50a/0x1750 [69832.304715] blkdev_ioctl+0x470/0x600 [69832.305474] block_ioctl+0xde/0x120 [69832.306232] vfs_ioctl+0x6c/0xc0 [69832.306877] __se_sys_ioctl+0x90/0xa0 [69832.307629] do_syscall_64+0x2d/0x40 [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [69832.309382] [69832.309701] Freed by task 155: [69832.310328] kasan_save_stack+0x19/0x40 [69832.311121] kasan_set_track+0x1c/0x30 [69832.311868] kasan_set_free_info+0x1b/0x30 [69832.312699] __kasan_slab_free+0x111/0x160 [69832.313524] kmem_cache_free+0x94/0x460 [69832.314367] bfq_put_queue+0x582/0x940 [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0 [69832.317275] bfq_bfqq_expire+0xb27/0x2440 [69832.318084] bfq_dispatch_request+0x697/0x44b0 [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830 [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0 [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140 [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270 [69832.323114] blk_mq_run_work_fn+0x51/0x6 ---truncated--- | ["https://git.kernel.org/stable/c/080665e2c3cbfc68359b9a348a3546ed9b908e7a","https://git.kernel.org/stable/c/40b4ba0030e0b02cbacd424ebb9f4c8b0976c786","https://git.kernel.org/stable/c/5117c9ff4c2ebae0f5c2c262d42a25a8fbc086e6","https://git.kernel.org/stable/c/5687958bf18f84384d809f521210d0f5deed03b0","https://git.kernel.org/stable/c/74e610b5ee0d95e751280567100509eb11517efa","https://git.kernel.org/stable/c/ab552fcb17cc9e4afe0e4ac4df95fc7b30e8490a","https://git.kernel.org/stable/c/df6e00b1a53c57dca82c63b5ecbcad5452231bc7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49179 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block, bfq: don't move oom_bfqq Our test report a UAF: [ 2073.019181] ================================================================== [ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584 [ 2073.019192] [ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5 [ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 2073.019200] Call trace: [ 2073.019203] dump_backtrace+0x0/0x310 [ 2073.019206] show_stack+0x28/0x38 [ 2073.019210] dump_stack+0xec/0x15c [ 2073.019216] print_address_description+0x68/0x2d0 [ 2073.019220] kasan_report+0x238/0x2f0 [ 2073.019224] __asan_store8+0x88/0xb0 [ 2073.019229] __bfq_put_async_bfqq+0xa0/0x168 [ 2073.019233] bfq_put_async_queues+0xbc/0x208 [ 2073.019236] bfq_pd_offline+0x178/0x238 [ 2073.019240] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019244] bfq_exit_queue+0x128/0x178 [ 2073.019249] blk_mq_exit_sched+0x12c/0x160 [ 2073.019252] elevator_exit+0xc8/0xd0 [ 2073.019256] blk_exit_queue+0x50/0x88 [ 2073.019259] blk_cleanup_queue+0x228/0x3d8 [ 2073.019267] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019274] null_exit+0x90/0x114 [null_blk] [ 2073.019278] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019282] el0_svc_common+0xc8/0x320 [ 2073.019287] el0_svc_handler+0xf8/0x160 [ 2073.019290] el0_svc+0x10/0x218 [ 2073.019291] [ 2073.019294] Allocated by task 14163: [ 2073.019301] kasan_kmalloc+0xe0/0x190 [ 2073.019305] kmem_cache_alloc_node_trace+0x1cc/0x418 [ 2073.019308] bfq_pd_alloc+0x54/0x118 [ 2073.019313] blkcg_activate_policy+0x250/0x460 [ 2073.019317] bfq_create_group_hierarchy+0x38/0x110 [ 2073.019321] bfq_init_queue+0x6d0/0x948 [ 2073.019325] blk_mq_init_sched+0x1d8/0x390 [ 2073.019330] elevator_switch_mq+0x88/0x170 [ 2073.019334] elevator_switch+0x140/0x270 [ 2073.019338] elv_iosched_store+0x1a4/0x2a0 [ 2073.019342] queue_attr_store+0x90/0xe0 [ 2073.019348] sysfs_kf_write+0xa8/0xe8 [ 2073.019351] kernfs_fop_write+0x1f8/0x378 [ 2073.019359] __vfs_write+0xe0/0x360 [ 2073.019363] vfs_write+0xf0/0x270 [ 2073.019367] ksys_write+0xdc/0x1b8 [ 2073.019371] __arm64_sys_write+0x50/0x60 [ 2073.019375] el0_svc_common+0xc8/0x320 [ 2073.019380] el0_svc_handler+0xf8/0x160 [ 2073.019383] el0_svc+0x10/0x218 [ 2073.019385] [ 2073.019387] Freed by task 72584: [ 2073.019391] __kasan_slab_free+0x120/0x228 [ 2073.019394] kasan_slab_free+0x10/0x18 [ 2073.019397] kfree+0x94/0x368 [ 2073.019400] bfqg_put+0x64/0xb0 [ 2073.019404] bfqg_and_blkg_put+0x90/0xb0 [ 2073.019408] bfq_put_queue+0x220/0x228 [ 2073.019413] __bfq_put_async_bfqq+0x98/0x168 [ 2073.019416] bfq_put_async_queues+0xbc/0x208 [ 2073.019420] bfq_pd_offline+0x178/0x238 [ 2073.019424] blkcg_deactivate_policy+0x1f0/0x420 [ 2073.019429] bfq_exit_queue+0x128/0x178 [ 2073.019433] blk_mq_exit_sched+0x12c/0x160 [ 2073.019437] elevator_exit+0xc8/0xd0 [ 2073.019440] blk_exit_queue+0x50/0x88 [ 2073.019443] blk_cleanup_queue+0x228/0x3d8 [ 2073.019451] null_del_dev+0xfc/0x1e0 [null_blk] [ 2073.019459] null_exit+0x90/0x114 [null_blk] [ 2073.019462] __arm64_sys_delete_module+0x358/0x5a0 [ 2073.019467] el0_svc_common+0xc8/0x320 [ 2073.019471] el0_svc_handler+0xf8/0x160 [ 2073.019474] el0_svc+0x10/0x218 [ 2073.019475] [ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00 which belongs to the cache kmalloc-1024 of size 1024 [ 2073.019484] The buggy address is located 552 bytes inside of 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300) [ 2073.019486] The buggy address belongs to the page: [ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0 [ 2073.020123] flags: 0x7ffff0000008100(slab|head) [ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00 [ 2073.020409] ra ---truncated--- | ["https://git.kernel.org/stable/c/7507ead1e9d42957c2340f2c4a0e9d00034e3366","https://git.kernel.org/stable/c/8410f70977734f21b8ed45c37e925d311dfda2e7","https://git.kernel.org/stable/c/87fdfe8589d43e471dffb4c60f75eeb6f37afc4c","https://git.kernel.org/stable/c/8f34dea99cd7761156a146a5258a67d045d862f7","https://git.kernel.org/stable/c/c01fced8d38fbccc82787065229578006f28e020","https://git.kernel.org/stable/c/c4f5a678add58a8a0e7ee5e038496b376ea6d205"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49288 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix races among concurrent prealloc proc writes We have no protection against concurrent PCM buffer preallocation changes via proc files, and it may potentially lead to UAF or some weird problem. This patch applies the PCM open_mutex to the proc write operation for avoiding the racy proc writes and the PCM stream open (and further operations). | ["https://git.kernel.org/stable/c/37b12c16beb6f6c1c3c678c1aacbc46525c250f7","https://git.kernel.org/stable/c/51fce708ab8986a9879ee5da946a2cc120f1036d","https://git.kernel.org/stable/c/5ed8f8e3c4e59d0396b9ccf2e639711e24295bb6","https://git.kernel.org/stable/c/69534c48ba8ce552ce383b3dfdb271ffe51820c3","https://git.kernel.org/stable/c/a21d2f323b5a978dedf9ff1d50f101f85e39b3f2","https://git.kernel.org/stable/c/b560d670c87d7d40b3cf6949246fa4c7aa65a00a","https://git.kernel.org/stable/c/e14dca613e0a6ddc2bf6e360f16936a9f865205b","https://git.kernel.org/stable/c/e7786c445bb67a9a6e64f66ebd6b7215b153ff7d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49410 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix potential double free in create_var_ref() In create_var_ref(), init_var_ref() is called to initialize the fields of variable ref_field, which is allocated in the previous function call to create_hist_field(). Function init_var_ref() allocates the corresponding fields such as ref_field->system, but frees these fields when the function encounters an error. The caller later calls destroy_hist_field() to conduct error handling, which frees the fields and the variable itself. This results in double free of the fields which are already freed in the previous function. Fix this by storing NULL to the corresponding fields when they are freed in init_var_ref(). | ["https://git.kernel.org/stable/c/058cb6d86b9789377216c936506b346aaa1eb581","https://git.kernel.org/stable/c/37443b3508b8cce6832f8d25cb4550b2f7801f50","https://git.kernel.org/stable/c/4fdfb15e08598711dbf50daf56a33965232daf0e","https://git.kernel.org/stable/c/99696a2592bca641eb88cc9a80c90e591afebd0f","https://git.kernel.org/stable/c/bd83ff3bbfb003832481c9bff999d12385f396ae","https://git.kernel.org/stable/c/c27f744ceefadc7bbeb14233b6abc150ced617d2","https://git.kernel.org/stable/c/f8b383f83cb573152c577eca1ef101e89995b72a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49455 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: misc: ocxl: fix possible double free in ocxl_file_register_afu info_release() will be called in device_unregister() when info->dev's reference count is 0. So there is no need to call ocxl_afu_put() and kfree() again. Fix this by adding free_minor() and return to err_unregister error path. | ["https://git.kernel.org/stable/c/252768d32e92c1214aeebb5fec0844ca479bcf5c","https://git.kernel.org/stable/c/8fb674216835e1f0c143762696d645facebb4685","https://git.kernel.org/stable/c/950cf957fe34d40d63dfa3bf3968210430b6491e","https://git.kernel.org/stable/c/9e9087cf34ee69f4e95d146ac29385d6e367a97b","https://git.kernel.org/stable/c/de65c32ace9aa70d51facc61ba986607075e3a25","https://git.kernel.org/stable/c/ee89d8dee55ab4b3b8ad8b70866b2841ba334767"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49489 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag] | ["https://git.kernel.org/stable/c/134760263f6441741db0b2970e7face6b34b6d1c","https://git.kernel.org/stable/c/5b0adf5cbf3b74721e4e4c4e0cadc91b8df8bcc2","https://git.kernel.org/stable/c/97ac682b6f7d36be5d934f86c9911066540a68f1","https://git.kernel.org/stable/c/aa4cb188988dc6f1b3f4917d4dbc452150a5d871","https://git.kernel.org/stable/c/ef10d0c68e8608848cd58fca2589685718426607","https://git.kernel.org/stable/c/ef4bdaac7cb5416f236613ed9337ff0ea8ee329b","https://git.kernel.org/stable/c/fa5186b279ecf44b14fb435540d2065be91cb1ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49524 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: Fix the error handling in cx23885_initdev() When the driver fails to call the dma_set_mask(), the driver will get the following splat: [ 55.853884] BUG: KASAN: use-after-free in __process_removed_driver+0x3c/0x240 [ 55.854486] Read of size 8 at addr ffff88810de60408 by task modprobe/590 [ 55.856822] Call Trace: [ 55.860327] __process_removed_driver+0x3c/0x240 [ 55.861347] bus_for_each_dev+0x102/0x160 [ 55.861681] i2c_del_driver+0x2f/0x50 This is because the driver has initialized the i2c related resources in cx23885_dev_setup() but not released them in error handling, fix this bug by modifying the error path that jumps after failing to call the dma_set_mask(). | ["https://git.kernel.org/stable/c/453514a874c78df1e7804e6e3aaa60c8d8deb6a8","https://git.kernel.org/stable/c/6041d1a0365baa729b6adfb6ed5386d9388018db","https://git.kernel.org/stable/c/7b9978e1c94e569d65a0e7e719abb9340f5db4a0","https://git.kernel.org/stable/c/86bd6a579c6c60547706cabf299cd2c9feab3332","https://git.kernel.org/stable/c/98106f100f50c487469903b9cf6d966785fc9cc3","https://git.kernel.org/stable/c/ca17e7a532d1a55466cc007b3f4d319541a27493","https://git.kernel.org/stable/c/e8123311cf06d7dae71e8c5fe78e0510d20cd30b","https://git.kernel.org/stable/c/fa636e9ee4442215cd9a2e079cd5a8e1fe0cb8ba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49626 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sfc: fix use after free when disabling sriov Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pci_dev: it was freed from pci_disable_sriov and later read in efx_ef10_sriov_free_vf_vports, called from efx_ef10_sriov_free_vf_vswitching. Set the pointer to NULL at release time to not trying to read it later. Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc] efx_ef10_pci_sriov_disable+0x38/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k allocated by task 6771 on cpu 10 at 3137.860196s: pci_alloc_dev+0x21/0x60 pci_iov_add_virtfn+0x2a2/0x320 sriov_enable+0x212/0x3e0 efx_ef10_sriov_configure+0x67/0x80 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xba/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae freed by task 6771 on cpu 12 at 3170.991309s: device_release+0x34/0x90 kobject_cleanup+0x3a/0x130 pci_iov_remove_virtfn+0xd9/0x120 sriov_disable+0x30/0xe0 efx_ef10_pci_sriov_disable+0x57/0x70 [sfc] efx_pci_sriov_configure+0x24/0x40 [sfc] sriov_numvfs_store+0xfe/0x140 kernfs_fop_write_iter+0x11c/0x1b0 new_sync_write+0x11f/0x1b0 vfs_write+0x1eb/0x280 ksys_write+0x5f/0xe0 do_syscall_64+0x5c/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/3199e34912d84cdfb8a93a984c5ae5c73fb13e84","https://git.kernel.org/stable/c/58d93e9d160c0de6d867c7eb4c2206671a351eb1","https://git.kernel.org/stable/c/9c854ae512b89229aeee93849e9bd4c115b37909","https://git.kernel.org/stable/c/bcad880865bfb421885364b1f0c7351280fe2b97","https://git.kernel.org/stable/c/c2240500817b3b4b996cdf2a461a3a5679f49b94","https://git.kernel.org/stable/c/c9e75bb22a26e391f189f5a5133dd63dcb57fdaa","https://git.kernel.org/stable/c/e435c4aeeaa073091f7f3b7735af2ef5c97d63f2","https://git.kernel.org/stable/c/ebe41da5d47ac0fff877e57bd14c54dccf168827"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49685 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: trigger: sysfs: fix use-after-free on remove Ensure that the irq_work has completed before the trigger is freed. ================================================================== BUG: KASAN: use-after-free in irq_work_run_list Read of size 8 at addr 0000000064702248 by task python3/25 Call Trace: irq_work_run_list irq_work_tick update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt Allocated by task 25: kmem_cache_alloc_trace iio_sysfs_trig_add dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write Freed by task 25: kfree iio_sysfs_trig_remove dev_attr_store sysfs_kf_write kernfs_fop_write_iter new_sync_write vfs_write ksys_write sys_write ================================================================== | ["https://git.kernel.org/stable/c/31ff3309b47d98313c61b8301bf595820cc3cc33","https://git.kernel.org/stable/c/4687c3f955240ca2a576bdc3f742d4d915b6272d","https://git.kernel.org/stable/c/4ef1e521be610b720daeb7cf899fedc7db0274c4","https://git.kernel.org/stable/c/5e39397d60dacc7f5d81d442c1c958eaaaf31128","https://git.kernel.org/stable/c/78601726d4a59a291acc5a52da1d3a0a6831e4e8","https://git.kernel.org/stable/c/b07a30a774b3c3e584a68dc91779c68ea2da4813","https://git.kernel.org/stable/c/d6111e7bdb8ec27eb43d01c4cd4ff1620a75f7f2","https://git.kernel.org/stable/c/fd5d8fb298a2866c337da635c79d63c3afabcaf7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21796 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: clear acl_access/acl_default after releasing them If getting acl_default fails, acl_access and acl_default will be released simultaneously. However, acl_access will still retain a pointer pointing to the released posix_acl, which will trigger a WARNING in nfs3svc_release_getacl like this: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28 refcount_warn_saturate+0xb5/0x170 Modules linked in: CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted 6.12.0-rc6-00079-g04ae226af01f-dirty #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb5/0x170 Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75 e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb cd 0f b6 1d 8a3 RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380 RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56 R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001 R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0 FS: 0000000000000000(0000) GS:ffff88871ed00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Kernel panic - not syncing: kernel: panic_on_warn set ... Clear acl_access/acl_default after posix_acl_release is called to prevent UAF from being triggered. | ["https://git.kernel.org/stable/c/1fd94884174bd20beb1773990fd3b1aa877688d9","https://git.kernel.org/stable/c/2e59b2b68782519560b3d6a41dd66a3d01a01cd3","https://git.kernel.org/stable/c/55d947315fb5f67a35e4e1d3e01bb886b9c6decf","https://git.kernel.org/stable/c/6f7cfee1a316891890c505563aa54f3476db52fd","https://git.kernel.org/stable/c/7faf14a7b0366f153284db0ad3347c457ea70136","https://git.kernel.org/stable/c/8a1737ae42c928384ab6447f6ee1a882510e85fa","https://git.kernel.org/stable/c/f8d871523142f7895f250a856f8c4a4181614510"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21811 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: protect access to buffers with no active references nilfs_lookup_dirty_data_buffers(), which iterates through the buffers attached to dirty data folios/pages, accesses the attached buffers without locking the folios/pages. For data cache, nilfs_clear_folio_dirty() may be called asynchronously when the file system degenerates to read only, so nilfs_lookup_dirty_data_buffers() still has the potential to cause use after free issues when buffers lose the protection of their dirty state midway due to this asynchronous clearing and are unintentionally freed by try_to_free_buffers(). Eliminate this race issue by adjusting the lock section in this function. | ["https://git.kernel.org/stable/c/367a9bffabe08c04f6d725032cce3d891b2b9e1a","https://git.kernel.org/stable/c/4b08d23d7d1917bef4fbee8ad81372f49b006656","https://git.kernel.org/stable/c/58c27fa7a610b6e8d44e6220e7dbddfbaccaf439","https://git.kernel.org/stable/c/72cf688d0ce7e642b12ddc9b2a42524737ec1b4a","https://git.kernel.org/stable/c/8e1b9201c9a24638cf09c6e1c9f224157328010b","https://git.kernel.org/stable/c/c437dfac9f7a5a46ac2a5e6d6acd3059e9f68188","https://git.kernel.org/stable/c/d8ff250e085a4c4cdda4ad1cdd234ed110393143","https://git.kernel.org/stable/c/e1fc4a90a90ea8514246c45435662531975937d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47639 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: x86/mmu: Zap _all_ roots when unmapping gfn range in TDP MMU Zap both valid and invalid roots when zapping/unmapping a gfn range, as KVM must ensure it holds no references to the freed page after returning from the unmap operation. Most notably, the TDP MMU doesn't zap invalid roots in mmu_notifier callbacks. This leads to use-after-free and other issues if the mmu_notifier runs to completion while an invalid root zapper yields as KVM fails to honor the requirement that there must be _no_ references to the page after the mmu_notifier returns. The bug is most easily reproduced by hacking KVM to cause a collision between set_nx_huge_pages() and kvm_mmu_notifier_release(), but the bug exists between kvm_mmu_notifier_invalidate_range_start() and memslot updates as well. Invalidating a root ensures pages aren't accessible by the guest, and KVM won't read or write page data itself, but KVM will trigger e.g. kvm_set_pfn_dirty() when zapping SPTEs, and thus completing a zap of an invalid root _after_ the mmu_notifier returns is fatal. WARNING: CPU: 24 PID: 1496 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:173 [kvm] RIP: 0010:kvm_is_zone_device_pfn+0x96/0xa0 [kvm] Call Trace: <TASK> kvm_set_pfn_dirty+0xa8/0xe0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] __handle_changed_spte+0x2ab/0x5e0 [kvm] zap_gfn_range+0x1f3/0x310 [kvm] kvm_tdp_mmu_zap_invalidated_roots+0x50/0x90 [kvm] kvm_mmu_zap_all_fast+0x177/0x1a0 [kvm] set_nx_huge_pages+0xb4/0x190 [kvm] param_attr_store+0x70/0x100 module_attr_store+0x19/0x30 kernfs_fop_write_iter+0x119/0x1b0 new_sync_write+0x11c/0x1b0 vfs_write+0x1cc/0x270 ksys_write+0x5f/0xe0 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> | ["https://git.kernel.org/stable/c/0c8a8da182d4333d9bbb9131d765145568c847b2","https://git.kernel.org/stable/c/8cf6f98ab1d16d5e607635a0c21c4231eb15367e","https://git.kernel.org/stable/c/af47248407c0c5ae52a752af1ab5ce5b0db91502","https://git.kernel.org/stable/c/d62007edf01f5c11f75d0f4b1e538fc52a5b1982"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47653 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: davinci: vpif: fix use-after-free on driver unbind The driver allocates and registers two platform device structures during probe, but the devices were never deregistered on driver unbind. This results in a use-after-free on driver unbind as the device structures were allocated using devres and would be freed by driver core when remove() returns. Fix this by adding the missing deregistration calls to the remove() callback and failing probe on registration errors. Note that the platform device structures must be freed using a proper release callback to avoid leaking associated resources like device names. | ["https://git.kernel.org/stable/c/43acb728bbc40169d2e2425e84a80068270974be","https://git.kernel.org/stable/c/6512c3c39cb6b573b791ce45365818a38b76afbe","https://git.kernel.org/stable/c/9ffc602e14d7b9f7e7cb2f67e18dfef9ef8af676","https://git.kernel.org/stable/c/b5a3bb7f6f164eb6ee74ef4898dcd019b2063448"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49076 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix use-after-free bug for mm struct Under certain conditions, such as MPI_Abort, the hfi1 cleanup code may represent the last reference held on the task mm. hfi1_mmu_rb_unregister() then drops the last reference and the mm is freed before the final use in hfi1_release_user_pages(). A new task may allocate the mm structure while it is still being used, resulting in problems. One manifestation is corruption of the mmap_sem counter leading to a hang in down_write(). Another is corruption of an mm struct that is in use by another task. | ["https://git.kernel.org/stable/c/0b7186d657ee55e2cdefae498f07d5c1961e8023","https://git.kernel.org/stable/c/2bbac98d0930e8161b1957dc0ec99de39ade1b3c","https://git.kernel.org/stable/c/5a9a1b24ddb510715f8f621263938186579a965c","https://git.kernel.org/stable/c/5f54364ff6cfcd14cddf5441c4a490bb28dd69f7","https://git.kernel.org/stable/c/9ca11bd8222a612de0d2f54d050bfcf61ae2883f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49082 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use after free in _scsih_expander_node_remove() The function mpt3sas_transport_port_remove() called in _scsih_expander_node_remove() frees the port field of the sas_expander structure, leading to the following use-after-free splat from KASAN when the ioc_info() call following that function is executed (e.g. when doing rmmod of the driver module): [ 3479.371167] ================================================================== [ 3479.378496] BUG: KASAN: use-after-free in _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.386936] Read of size 1 at addr ffff8881c037691c by task rmmod/1531 [ 3479.393524] [ 3479.395035] CPU: 18 PID: 1531 Comm: rmmod Not tainted 5.17.0-rc8+ #1436 [ 3479.401712] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.1 06/02/2021 [ 3479.409263] Call Trace: [ 3479.411743] <TASK> [ 3479.413875] dump_stack_lvl+0x45/0x59 [ 3479.417582] print_address_description.constprop.0+0x1f/0x120 [ 3479.423389] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.429469] kasan_report.cold+0x83/0xdf [ 3479.433438] ? _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.439514] _scsih_expander_node_remove+0x710/0x750 [mpt3sas] [ 3479.445411] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 3479.452032] scsih_remove+0x525/0xc90 [mpt3sas] [ 3479.458212] ? mpt3sas_expander_remove+0x1d0/0x1d0 [mpt3sas] [ 3479.465529] ? down_write+0xde/0x150 [ 3479.470746] ? up_write+0x14d/0x460 [ 3479.475840] ? kernfs_find_ns+0x137/0x310 [ 3479.481438] pci_device_remove+0x65/0x110 [ 3479.487013] __device_release_driver+0x316/0x680 [ 3479.493180] driver_detach+0x1ec/0x2d0 [ 3479.498499] bus_remove_driver+0xe7/0x2d0 [ 3479.504081] pci_unregister_driver+0x26/0x250 [ 3479.510033] _mpt3sas_exit+0x2b/0x6cf [mpt3sas] [ 3479.516144] __x64_sys_delete_module+0x2fd/0x510 [ 3479.522315] ? free_module+0xaa0/0xaa0 [ 3479.527593] ? __cond_resched+0x1c/0x90 [ 3479.532951] ? lockdep_hardirqs_on_prepare+0x273/0x3e0 [ 3479.539607] ? syscall_enter_from_user_mode+0x21/0x70 [ 3479.546161] ? trace_hardirqs_on+0x1c/0x110 [ 3479.551828] do_syscall_64+0x35/0x80 [ 3479.556884] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3479.563402] RIP: 0033:0x7f1fc482483b ... [ 3479.943087] ================================================================== Fix this by introducing the local variable port_id to store the port ID value before executing mpt3sas_transport_port_remove(). This local variable is then used in the call to ioc_info() instead of dereferencing the freed port structure. | ["https://git.kernel.org/stable/c/17d66b1c92bcb41e72271ec60069d3684aaa1c9c","https://git.kernel.org/stable/c/1bb8a7fc64d63ec818e367e1b37676ea2ef2d20c","https://git.kernel.org/stable/c/25c1353dca74ad7cf3fd7ce258fe7c957a147d5e","https://git.kernel.org/stable/c/87d663d40801dffc99a5ad3b0188ad3e2b4d1557"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49093 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: skbuff: fix coalescing for page_pool fragment recycling Fix a use-after-free when using page_pool with page fragments. We encountered this problem during normal RX in the hns3 driver: (1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through page_pool, and the other two allocate one half of PAGE2 each. Page references look like this: RX_BD1 _______ PAGE1 RX_BD2 _______ PAGE2 RX_BD3 _________/ (2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcp_queue_rcv(). (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netif_receive_skb(): netif_receive_skb(SKB2) ip_rcv(SKB2) SKB3 = skb_clone(SKB2) SKB2 and SKB3 share a reference to PAGE2 through skb_shinfo()->dataref. The other ref to PAGE2 is still held by RX_BD3: SKB2 ---+- PAGE2 SKB3 __/ / RX_BD3 _________/ (3b) Now while handling TCP, coalesce SKB3 with SKB1: tcp_v4_rcv(SKB3) tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds kfree_skb_partial(SKB3) skb_release_data(SKB3) // drops one dataref SKB1 _____ PAGE1 \____ SKB2 _____ PAGE2 / RX_BD3 _________/ In skb_try_coalesce(), __skb_frag_ref() takes a page reference to PAGE2, where it should instead have increased the page_pool frag reference, pp_frag_count. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow. (3c) Drop SKB2: af_packet_rcv(SKB2) consume_skb(SKB2) skb_release_data(SKB2) // drops second dataref page_pool_return_skb_page(PAGE2) // drops one pp_frag_count SKB1 _____ PAGE1 \____ PAGE2 / RX_BD3 _________/ (4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well: tcp_eat_recv_skb(SKB1) skb_release_data(SKB1) page_pool_return_skb_page(PAGE1) page_pool_return_skb_page(PAGE2) // drops second pp_frag_count (5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled. Change the logic that checks whether pp_recycle SKBs can be coalesced. We still reject differing pp_recycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pp_recycled and 'from' is cloned. The new logic allows coalescing a cloned pp_recycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skb_try_coalesce(). | ["https://git.kernel.org/stable/c/1effe8ca4e34c34cdd9318436a4232dcb582ebf4","https://git.kernel.org/stable/c/72bb856d16e883437023ff2ff77d0c498018728a","https://git.kernel.org/stable/c/ba965e8605aee5387cecaa28fcf7ee9f61779a49","https://git.kernel.org/stable/c/c4fa19615806a9a7e518c295b39175aa47a685ac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49129 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix crash when startup fails. If the nic fails to start, it is possible that the reset_work has already been scheduled. Ensure the work item is canceled so we do not have use-after-free crash in case cleanup is called before the work item is executed. This fixes crash on my x86_64 apu2 when mt7921k radio fails to work. Radio still fails, but OS does not crash. | ["https://git.kernel.org/stable/c/38fbe806645090c07aa97171f20fc62c3d7d3a98","https://git.kernel.org/stable/c/827e7799c61b978fbc2cc9dac66cb62401b2b3f0","https://git.kernel.org/stable/c/ac1260b661c2ef0d0a56680cdb5672b931b7be8f","https://git.kernel.org/stable/c/c1a5e6002ec441a3b9fb4d048b4b49ae93409a46"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49182 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: add vlan list lock to protect vlan list When adding port base VLAN, vf VLAN need to remove from HW and modify the vlan state in vf VLAN list as false. If the periodicity task is freeing the same node, it may cause "use after free" error. This patch adds a vlan list lock to protect the vlan list. | ["https://git.kernel.org/stable/c/09e383ca97e798f9954189b741af54b5c51e7a97","https://git.kernel.org/stable/c/1932a624ab88ff407d1a1d567fe581faa15dc725","https://git.kernel.org/stable/c/30f0ff7176efe8ac6c55f85bce26ed58bb608758","https://git.kernel.org/stable/c/f58af41deeab0f45c9c80adf5f2de489ebbac3dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49196 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Fix use after free in remove_phb_dynamic() In remove_phb_dynamic() we use &phb->io_resource, after we've called device_unregister(&host_bridge->dev). But the unregister may have freed phb, because pcibios_free_controller_deferred() is the release function for the host_bridge. If there are no outstanding references when we call device_unregister() then phb will be freed out from under us. This has gone mainly unnoticed, but with slub_debug and page_poison enabled it can lead to a crash: PID: 7574 TASK: c0000000d492cb80 CPU: 13 COMMAND: "drmgr" #0 [c0000000e4f075a0] crash_kexec at c00000000027d7dc #1 [c0000000e4f075d0] oops_end at c000000000029608 #2 [c0000000e4f07650] __bad_page_fault at c0000000000904b4 #3 [c0000000e4f076c0] do_bad_slb_fault at c00000000009a5a8 #4 [c0000000e4f076f0] data_access_slb_common_virt at c000000000008b30 Data SLB Access [380] exception frame: R0: c000000000167250 R1: c0000000e4f07a00 R2: c000000002a46100 R3: c000000002b39ce8 R4: 00000000000000c0 R5: 00000000000000a9 R6: 3894674d000000c0 R7: 0000000000000000 R8: 00000000000000ff R9: 0000000000000100 R10: 6b6b6b6b6b6b6b6b R11: 0000000000008000 R12: c00000000023da80 R13: c0000009ffd38b00 R14: 0000000000000000 R15: 000000011c87f0f0 R16: 0000000000000006 R17: 0000000000000003 R18: 0000000000000002 R19: 0000000000000004 R20: 0000000000000005 R21: 000000011c87ede8 R22: 000000011c87c5a8 R23: 000000011c87d3a0 R24: 0000000000000000 R25: 0000000000000001 R26: c0000000e4f07cc8 R27: c00000004d1cc400 R28: c0080000031d00e8 R29: c00000004d23d800 R30: c00000004d1d2400 R31: c00000004d1d2540 NIP: c000000000167258 MSR: 8000000000009033 OR3: c000000000e9f474 CTR: 0000000000000000 LR: c000000000167250 XER: 0000000020040003 CCR: 0000000024088420 MQ: 0000000000000000 DAR: 6b6b6b6b6b6b6ba3 DSISR: c0000000e4f07920 Syscall Result: fffffffffffffff2 [NIP : release_resource+56] [LR : release_resource+48] #5 [c0000000e4f07a00] release_resource at c000000000167258 (unreliable) #6 [c0000000e4f07a30] remove_phb_dynamic at c000000000105648 #7 [c0000000e4f07ab0] dlpar_remove_slot at c0080000031a09e8 [rpadlpar_io] #8 [c0000000e4f07b50] remove_slot_store at c0080000031a0b9c [rpadlpar_io] #9 [c0000000e4f07be0] kobj_attr_store at c000000000817d8c #10 [c0000000e4f07c00] sysfs_kf_write at c00000000063e504 #11 [c0000000e4f07c20] kernfs_fop_write_iter at c00000000063d868 #12 [c0000000e4f07c70] new_sync_write at c00000000054339c #13 [c0000000e4f07d10] vfs_write at c000000000546624 #14 [c0000000e4f07d60] ksys_write at c0000000005469f4 #15 [c0000000e4f07db0] system_call_exception at c000000000030840 #16 [c0000000e4f07e10] system_call_vectored_common at c00000000000c168 To avoid it, we can take a reference to the host_bridge->dev until we're done using phb. Then when we drop the reference the phb will be freed. | ["https://git.kernel.org/stable/c/33d39efb61a84e055ca2386157d39ebbdf6b7d31","https://git.kernel.org/stable/c/403f9e0bc5535a0a5184d1352fa3a70e6ffacb6f","https://git.kernel.org/stable/c/895ca4ae1f72e0a0160ab162723e59c9f265ec93","https://git.kernel.org/stable/c/fe2640bd7a62f1f7c3f55fbda31084085075bc30"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49223 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cxl/port: Hold port reference until decoder release KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in cxl_decoder_release() where it goes to reference its parent, a cxl_port, to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: <TASK> dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0 The device core only guarantees parent lifetime until all children are unregistered. If a child needs a parent to complete its ->release() callback that child needs to hold a reference to extend the lifetime of the parent. | ["https://git.kernel.org/stable/c/49f2dab77a5e1354f5da6ccdc9346a8212697be2","https://git.kernel.org/stable/c/518bb96367123062b48b0a9842f2864249b565f6","https://git.kernel.org/stable/c/74be98774dfbc5b8b795db726bd772e735d2edd4","https://git.kernel.org/stable/c/b0022ca445d5fc4d0c89d15dcd0f855977b22c1d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49236 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF due to race between btf_try_get_module and load_module While working on code to populate kfunc BTF ID sets for module BTF from its initcall, I noticed that by the time the initcall is invoked, the module BTF can already be seen by userspace (and the BPF verifier). The existing btf_try_get_module calls try_module_get which only fails if mod->state == MODULE_STATE_GOING, i.e. it can increment module reference when module initcall is happening in parallel. Currently, BTF parsing happens from MODULE_STATE_COMING notifier callback. At this point, the module initcalls have not been invoked. The notifier callback parses and prepares the module BTF, allocates an ID, which publishes it to userspace, and then adds it to the btf_modules list allowing the kernel to invoke btf_try_get_module for the BTF. However, at this point, the module has not been fully initialized (i.e. its initcalls have not finished). The code in module.c can still fail and free the module, without caring for other users. However, nothing stops btf_try_get_module from succeeding between the state transition from MODULE_STATE_COMING to MODULE_STATE_LIVE. This leads to a use-after-free issue when BPF program loads successfully in the state transition, load_module's do_init_module call fails and frees the module, and BPF program fd on close calls module_put for the freed module. Future patch has test case to verify we don't regress in this area in future. There are multiple points after prepare_coming_module (in load_module) where failure can occur and module loading can return error. We illustrate and test for the race using the last point where it can practically occur (in module __init function). An illustration of the race: CPU 0 CPU 1 load_module notifier_call(MODULE_STATE_COMING) btf_parse_module btf_alloc_id // Published to userspace list_add(&btf_mod->list, btf_modules) mod->init(...) ... ^ bpf_check | check_pseudo_btf_id | btf_try_get_module | returns true | ... ... | module __init in progress return prog_fd | ... ... V if (ret < 0) free_module(mod) ... close(prog_fd) ... bpf_prog_free_deferred module_put(used_btf.mod) // use-after-free We fix this issue by setting a flag BTF_MODULE_F_LIVE, from the notifier callback when MODULE_STATE_LIVE state is reached for the module, so that we return NULL from btf_try_get_module for modules that are not fully formed. Since try_module_get already checks that module is not in MODULE_STATE_GOING state, and that is the only transition a live module can make before being removed from btf_modules list, this is enough to close the race and prevent the bug. A later selftest patch crafts the race condition artifically to verify that it has been fixed, and that verifier fails to load program (with ENXIO). Lastly, a couple of comments: 1. Even if this race didn't exist, it seems more appropriate to only access resources (ksyms and kfuncs) of a fully formed module which has been initialized completely. 2. This patch was born out of need for synchronization against module initcall for the next patch, so it is needed for correctness even without the aforementioned race condition. The BTF resources initialized by module initcall are set up once and then only looked up, so just waiting until the initcall has finished ensures correct behavior. | ["https://git.kernel.org/stable/c/0481baa2318cb1ab13277715da6cdbb657807b3f","https://git.kernel.org/stable/c/18688de203b47e5d8d9d0953385bf30b5949324f","https://git.kernel.org/stable/c/51b82141fffa454abf937a8ff0b8af89e4fd0c8f","https://git.kernel.org/stable/c/d7fccf264b1a785525b366a5b7f8113c756187ad"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49258 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: ccree - Fix use after free in cc_cipher_exit() kfree_sensitive(ctx_p->user.key) will free the ctx_p->user.key. But ctx_p->user.key is still used in the next line, which will lead to a use after free. We can call kfree_sensitive() after dev_dbg() to avoid the uaf. | ["https://git.kernel.org/stable/c/25c358efee5153dfd240d4e0d3169d5bebe9cacd","https://git.kernel.org/stable/c/335bf1fc74f775a8255257aa3e33763f2257b676","https://git.kernel.org/stable/c/3d950c34074ed74d2713c3856ba01264523289e6","https://git.kernel.org/stable/c/c93017c8d5ebf55a4e453ac7c84cc84cf92ab570","https://git.kernel.org/stable/c/cffb5382bd8d3cf21b874ab5b84bf7618932286b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49270 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm: fix use-after-free in dm_cleanup_zoned_dev() dm_cleanup_zoned_dev() uses queue, so it must be called before blk_cleanup_disk() starts its killing: blk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()-> ->...RCU...->blk_free_queue_rcu()->kmem_cache_free() Otherwise, RCU callback may be executed first and dm_cleanup_zoned_dev() will touch free'd memory: BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0 Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681 CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x57/0x7d print_address_description.constprop.0+0x1f/0x150 ? dm_cleanup_zoned_dev+0x33/0xd0 kasan_report.cold+0x7f/0x11b ? dm_cleanup_zoned_dev+0x33/0xd0 dm_cleanup_zoned_dev+0x33/0xd0 __dm_destroy+0x26a/0x400 ? dm_blk_ioctl+0x230/0x230 ? up_write+0xd8/0x270 dev_remove+0x156/0x1d0 ctl_ioctl+0x269/0x530 ? table_clear+0x140/0x140 ? lock_release+0xb2/0x750 ? remove_all+0x40/0x40 ? rcu_read_lock_sched_held+0x12/0x70 ? lock_downgrade+0x3c0/0x3c0 ? rcu_read_lock_sched_held+0x12/0x70 dm_ctl_ioctl+0xa/0x10 __x64_sys_ioctl+0xb9/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fb6dfa95c27 | ["https://git.kernel.org/stable/c/0987f00a76a17aa7213da492c00ed9e5a6210c73","https://git.kernel.org/stable/c/43a043aed964659bc69ef81f266912b73c80d837","https://git.kernel.org/stable/c/588b7f5df0cb64f281290c7672470c006abe7160","https://git.kernel.org/stable/c/fdfe414ca28ddfd562c233fb27385cf820de03e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49384 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: fix double free of io_acct_set bioset Now io_acct_set is alloc and free in personality. Remove the codes that free io_acct_set in md_free and md_stop. | ["https://git.kernel.org/stable/c/36a2fc44c574a59ee3b5e2cb327182f227b2b07e","https://git.kernel.org/stable/c/42b805af102471f53e3c7867b8c2b502ea4eef7e","https://git.kernel.org/stable/c/ea7d7bd90079d96f9c86bdaf0b106e0cd2a70661","https://git.kernel.org/stable/c/f99d5b5dc8a42c807b5f1176b925aa45d61962ab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49470 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_event We should not access skb buffer data anymore after hci_recv_frame was called. [ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0 [ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker [ 39.634962] Call trace: [ 39.634974] dump_backtrace+0x0/0x3b8 [ 39.634999] show_stack+0x20/0x2c [ 39.635016] dump_stack_lvl+0x60/0x78 [ 39.635040] print_address_description+0x70/0x2f0 [ 39.635062] kasan_report+0x154/0x194 [ 39.635079] __asan_report_load1_noabort+0x44/0x50 [ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4 [ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4 [ 39.635157] process_one_work+0x560/0xc5c [ 39.635177] worker_thread+0x7ec/0xcc0 [ 39.635195] kthread+0x2d0/0x3d0 [ 39.635215] ret_from_fork+0x10/0x20 [ 39.635247] Allocated by task 0: [ 39.635260] (stack is not available) [ 39.635281] Freed by task 2392: [ 39.635295] kasan_save_stack+0x38/0x68 [ 39.635319] kasan_set_track+0x28/0x3c [ 39.635338] kasan_set_free_info+0x28/0x4c [ 39.635357] ____kasan_slab_free+0x104/0x150 [ 39.635374] __kasan_slab_free+0x18/0x28 [ 39.635391] slab_free_freelist_hook+0x114/0x248 [ 39.635410] kfree+0xf8/0x2b4 [ 39.635427] skb_free_head+0x58/0x98 [ 39.635447] skb_release_data+0x2f4/0x410 [ 39.635464] skb_release_all+0x50/0x60 [ 39.635481] kfree_skb+0xc8/0x25c [ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth] [ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth] [ 39.635925] process_one_work+0x560/0xc5c [ 39.635951] worker_thread+0x7ec/0xcc0 [ 39.635970] kthread+0x2d0/0x3d0 [ 39.635990] ret_from_fork+0x10/0x20 [ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512 [ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800) | ["https://git.kernel.org/stable/c/01c6a899fa6be4f4cbf60c4f44f0f6691155415f","https://git.kernel.org/stable/c/02ba31e09a26e8cd4582ac8e6163d80284997727","https://git.kernel.org/stable/c/0fab6361c4ba17d1b43a991bef4238a3c1754d35","https://git.kernel.org/stable/c/b3cec8a42fcd11d05313c724f27e01b1db77522c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49501 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usbnet: Run unregister_netdev() before unbind() again Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()") sought to fix a use-after-free on disconnect of USB Ethernet adapters. It turns out that a different fix is necessary to address the issue: https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/ So the commit was not necessary. The commit made binding and unbinding of USB Ethernet asymmetrical: Before, usbnet_probe() first invoked the ->bind() callback and then register_netdev(). usbnet_disconnect() mirrored that by first invoking unregister_netdev() and then ->unbind(). Since the commit, the order in usbnet_disconnect() is reversed and no longer mirrors usbnet_probe(). One consequence is that a PHY disconnected (and stopped) in ->unbind() is afterwards stopped once more by unregister_netdev() as it closes the netdev before unregistering. That necessitates a contortion in ->stop() because the PHY may only be stopped if it hasn't already been disconnected. Reverting the commit allows making the call to phy_stop() unconditional in ->stop(). | ["https://git.kernel.org/stable/c/6d5deb242874d924beccf7eb3cef04c1c3b0da79","https://git.kernel.org/stable/c/969a1b3ea3cb7d58a16fe12fd1b04bfc0ea40509","https://git.kernel.org/stable/c/d1408f6b4dd78fb1b9e26bcf64477984e5f85409","https://git.kernel.org/stable/c/fbda837107f9bd4ec658d2aa88c6856dba606f06"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57984 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition In dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work. If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | dw_i3c_hj_work dw_i3c_common_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in dw_i3c_common_remove. | ["https://git.kernel.org/stable/c/60d2fb033a999bb644f8e8606ff4a1b82de36c6f","https://git.kernel.org/stable/c/9b0063098fcde17cd2894f2c96459b23388507ca","https://git.kernel.org/stable/c/b75439c945b94dd8a2b645355bdb56f948052601","https://git.kernel.org/stable/c/fc84dd3c909a372c0d130f5f84c404717c17eed8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21759 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: extend RCU protection in igmp6_send() igmp6_send() can be called without RTNL or RCU being held. Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF. Note that we no longer can use sock_alloc_send_skb() because ipv6.igmp_sk uses GFP_KERNEL allocations which can sleep. Instead use alloc_skb() and charge the net->ipv6.igmp_sk socket under RCU protection. | ["https://git.kernel.org/stable/c/087c1faa594fa07a66933d750c0b2610aa1a2946","https://git.kernel.org/stable/c/0bf8e2f3768629d437a32cb824149e6e98254381","https://git.kernel.org/stable/c/81b25a07ebf53f9ef4ca8f3d96a8ddb94561dd5a","https://git.kernel.org/stable/c/8e92d6a413feaf968a33f0b439ecf27404407458"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21812 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ax25: rcu protect dev->ax25_ptr syzbot found a lockdep issue [1]. We should remove ax25 RTNL dependency in ax25_setsockopt() This should also fix a variety of possible UAF in ax25. [1] WARNING: possible circular locking dependency detected 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted ------------------------------------------------------ syz.5.1818/12806 is trying to acquire lock: ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 but task is already holding lock: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (sk_lock-AF_AX25){+.+.}-{0:0}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 lock_sock_nested+0x48/0x100 net/core/sock.c:3642 lock_sock include/net/sock.h:1618 [inline] ax25_kill_by_device net/ax25/af_ax25.c:101 [inline] ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146 notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026 dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563 dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820 sock_do_ioctl+0x240/0x460 net/socket.c:1234 sock_ioctl+0x626/0x8e0 net/socket.c:1339 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (rtnl_mutex){+.+.}-{4:4}: check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/locking/lockdep.c:3280 [inline] validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904 __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __mutex_lock_common kernel/locking/mutex.c:585 [inline] __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735 ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680 do_sock_setsockopt+0x3af/0x720 net/socket.c:2324 __sys_setsockopt net/socket.c:2349 [inline] __do_sys_setsockopt net/socket.c:2355 [inline] __se_sys_setsockopt net/socket.c:2352 [inline] __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(sk_lock-AF_AX25); lock(rtnl_mutex); lock(sk_lock-AF_AX25); lock(rtnl_mutex); *** DEADLOCK *** 1 lock held by syz.5.1818/12806: #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline] #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574 stack backtrace: CPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206 check_prev_add kernel/locking/lockdep.c:3161 [inline] check_prevs_add kernel/lockin ---truncated--- | ["https://git.kernel.org/stable/c/2802ed4ced27ebd474828fc67ffd7d66f11e3605","https://git.kernel.org/stable/c/7705d8a7f2c26c80973c81093db07c6022b2b30e","https://git.kernel.org/stable/c/8937f5e38a218531dce2a89fae60e3adcc2311e1","https://git.kernel.org/stable/c/95fc45d1dea8e1253f8ec58abc5befb71553d666","https://git.kernel.org/stable/c/c2531db6de3c95551be58878f859c6a053b7eb2e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-54458 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: bsg: Set bsg_queue to NULL after removal Currently, this does not cause any issues, but I believe it is necessary to set bsg_queue to NULL after removing it to prevent potential use-after-free (UAF) access. | ["https://git.kernel.org/stable/c/1e95c798d8a7f70965f0f88d4657b682ff0ec75f","https://git.kernel.org/stable/c/22018622e1e9e371198dbd983af946a844d5924c","https://git.kernel.org/stable/c/5e7b6e44468c3242c21c2a8656d009fb3eb50a73","https://git.kernel.org/stable/c/5f782d4741bf558def60df192b858b0efc6a5f0a","https://git.kernel.org/stable/c/88a01e9c9ad40c075756ba93b47984461d4ff15d","https://git.kernel.org/stable/c/9193bdc170cc23fe98aca71d1a63c0bf6e1e853b","https://git.kernel.org/stable/c/bb4783c670180b922267222408e1c48d22dfbb46"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58034 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code() As of_find_node_by_name() release the reference of the argument device node, tegra_emc_find_node_by_ram_code() releases some device nodes while still in use, resulting in possible UAFs. According to the bindings and the in-tree DTS files, the "emc-tables" node is always device's child node with the property "nvidia,use-ram-code", and the "lpddr2" node is a child of the "emc-tables" node. Thus utilize the for_each_child_of_node() macro and of_get_child_by_name() instead of of_find_node_by_name() to simplify the code. This bug was found by an experimental verification tool that I am developing. [krzysztof: applied v1, adjust the commit msg to incorporate v2 parts] | ["https://git.kernel.org/stable/c/3b02273446e23961d910b50cc12528faec649fb2","https://git.kernel.org/stable/c/755e44538c190c31de9090d8e8821d228fcfd416","https://git.kernel.org/stable/c/b9784e5cde1f9fb83661a70e580e381ae1264d12","https://git.kernel.org/stable/c/c144423cb07e4e227a8572d5742ca2b36ada770d","https://git.kernel.org/stable/c/c3def10c610ae046aaa61d00528e7bd15e4ad8d3","https://git.kernel.org/stable/c/e9d07e91de140679eeaf275f47ad154467cb9e05"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21722 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: do not force clear folio if buffer is referenced Patch series "nilfs2: protect busy buffer heads from being force-cleared". This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue. This patch (of 2): Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur. One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The other is when nilfs_btree_propagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback. Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is. | ["https://git.kernel.org/stable/c/1098bb8d52419d262a3358d099a1598a920b730f","https://git.kernel.org/stable/c/19296737024cd220a1d6590bf4c092bca8c99497","https://git.kernel.org/stable/c/4d042811c72f71be7c14726db2c72b67025a7cb5","https://git.kernel.org/stable/c/557ccf5e49f1fb848a29698585bcab2e50a597ef","https://git.kernel.org/stable/c/7d0544bacc11d6aa26ecd7debf9353193c7a3328","https://git.kernel.org/stable/c/ca76bb226bf47ff04c782cacbd299f12ddee1ec1","https://git.kernel.org/stable/c/f51ff43c4c5a6c8e72d0aca89e4d5e688938412f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21726 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: padata: avoid UAF for reorder_work Although the previous patch can avoid ps and ps UAF for _do_serial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below: crypto_request crypto_request crypto_del_alg padata_do_serial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... } padata_do_serial // new request added list_add // sees the new request queue_work(reorder_work) padata_reorder queue_work_on(squeue->work) ... <kworker context> padata_serial_worker // completes new request, // no more outstanding // requests crypto_del_alg // free pd <kworker context> invoke_padata_reorder // UAF of pd To avoid UAF for 'reorder_work', get 'pd' ref before put 'reorder_work' into the 'serial_wq' and put 'pd' ref until the 'serial_wq' finish. | ["https://git.kernel.org/stable/c/4c6209efea2208597dbd3e52dc87a0d1a8f2dbe1","https://git.kernel.org/stable/c/6f45ef616775b0ce7889b0f6077fc8d681ab30bc","https://git.kernel.org/stable/c/7000507bb0d2ceb545c0a690e0c707c897d102c2","https://git.kernel.org/stable/c/8ca38d0ca8c3d30dd18d311f1a7ec5cb56972cac","https://git.kernel.org/stable/c/a54091c24220a4cd847d5b4f36d678edacddbaf0","https://git.kernel.org/stable/c/dd7d37ccf6b11f3d95e797ebe4e9e886d0332600","https://git.kernel.org/stable/c/f4f1b1169fc3694f9bc3e28c6c68dbbf4cc744c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21727 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: padata: fix UAF in padata_reorder A bug was found when run ltp test: BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206 CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecrypt_parallel padata_parallel_worker Call Trace: <TASK> dump_stack_lvl+0x32/0x50 print_address_description.constprop.0+0x6b/0x3d0 print_report+0xdd/0x2c0 kasan_report+0xa5/0xd0 padata_find_next+0x29/0x1a0 padata_reorder+0x131/0x220 padata_parallel_worker+0x3d/0xc0 process_one_work+0x2ec/0x5a0 If 'mdelay(10)' is added before calling 'padata_find_next' in the 'padata_reorder' function, this issue could be reproduced easily with ltp test (pcrypt_aead01). This can be explained as bellow: pcrypt_aead_encrypt ... padata_do_parallel refcount_inc(&pd->refcnt); // add refcnt ... padata_do_serial padata_reorder // pd while (1) { padata_find_next(pd, true); // using pd queue_work_on ... padata_serial_worker crypto_del_alg padata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed // loop again, but pd is freed // call padata_find_next, UAF } In the padata_reorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padata_find_next', which leads to UAF. As mentioned in [1], do_serial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls to finish. [1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/ | ["https://git.kernel.org/stable/c/0ae2f332cfd2d74cf3ce344ec9938cf3e29c3ccd","https://git.kernel.org/stable/c/573ac9c70bf7885dc85d82fa44550581bfc3b738","https://git.kernel.org/stable/c/80231f069240d52e98b6a317456c67b2eafd0781","https://git.kernel.org/stable/c/bbccae982e9fa1d7abcb23a5ec81cb0ec883f7de","https://git.kernel.org/stable/c/e01780ea4661172734118d2a5f41bc9720765668","https://git.kernel.org/stable/c/f3e0b9f790f8e8065d59e67b565a83154d9f3079","https://git.kernel.org/stable/c/f78170bee51469734b1a306a74fc5f777bb22ba6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49753 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: Fix double increment of client_count in dma_chan_get() The first time dma_chan_get() is called for a channel the channel client_count is incorrectly incremented twice for public channels, first in balance_ref_count(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of async_tx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning. [ 124.329662] async_tx: api initialized (async) [ 129.000627] async_tx: api initialized (async) [ 130.047839] ------------[ cut here ]------------ [ 130.052472] refcount_t: underflow; use-after-free. [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110 [ 130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr intel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm mgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si syscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops k10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat fat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul libahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas i40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash dm_log dm_mod [last unloaded: async_tx] [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not tainted 5.14.0-185.el9.x86_64 #1 [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 01/17/2022 [ 130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110 [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Call Trace: [ 130.222192] <TASK> [ 130.224305] dma_chan_put+0x10d/0x110 [ 130.227988] dmaengine_put+0x7a/0xa0 [ 130.231575] __do_sys_delete_module.constprop.0+0x178/0x280 [ 130.237157] ? syscall_trace_enter.constprop.0+0x145/0x1d0 [ 130.242652] do_syscall_64+0x5c/0x90 [ 130.246240] ? exc_page_fault+0x62/0x150 [ 130.250178] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] </TASK> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]--- cat /sys/class/dma/dma0chan*/in_use would get the wrong result. 2 2 2 Test-by: Jie Hai <haijie1@huawei.com> | ["https://git.kernel.org/stable/c/142d644fd2cc059ffa042fbfb68e766433ef3afd","https://git.kernel.org/stable/c/18dd3b30d4c7e8440c63118c7a7b687372b9567f","https://git.kernel.org/stable/c/1b409e14b4b7af034e0450f95c165b6c5c87dbc1","https://git.kernel.org/stable/c/42ecd72f02cd657b00b559621e7ef7d2c4d3e5f1","https://git.kernel.org/stable/c/71c601965532c38030133535f7cd93c1efa75af1","https://git.kernel.org/stable/c/c6221afe573413fd2981e291f7df4a58283e0654","https://git.kernel.org/stable/c/f3dc1b3b4750851a94212dba249703dd0e50bb20"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58013 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961 CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci0 hci_cmd_sync_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 16026: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:726 sock_write_iter+0x2d7/0x3f0 net/socket.c:1147 new_sync_write fs/read_write.c:586 [inline] vfs_write+0xaeb/0xd30 fs/read_write.c:679 ksys_write+0x18f/0x2b0 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 16022: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kfree+0x196/0x420 mm/slub.c:4746 mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550 hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208 hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 sock_do_ioctl+0x158/0x460 net/socket.c:1209 sock_ioctl+0x626/0x8e0 net/socket.c:1328 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/0f3d05aacbfcf3584bbd9caaee34cb02508dab68","https://git.kernel.org/stable/c/26fbd3494a7dd26269cb0817c289267dbcfdec06","https://git.kernel.org/stable/c/4ebbcb9bc794e5be647ee28fdf14eb1ae0659405","https://git.kernel.org/stable/c/75e65b983c5e2ee51962bfada98a79d805f28827","https://git.kernel.org/stable/c/ebb90f23f0ac21044aacf4c61cc5d7841fe99987"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26589 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". | ["https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3","https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed","https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0","https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8","https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d","https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3","https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed","https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0","https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8","https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1078 | High | fixed |
|
A flaw was found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info` actually points to something else that is potentially controlled by local user. It is known how to trigger this, which causes an out of bounds access, and a lock corruption. | ["http://www.openwall.com/lists/oss-security/2023/11/05/1","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230505-0004/","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230505-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49894 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max | ["https://git.kernel.org/stable/c/07078fa5d589a7fbce8f81ea8acf7aa0021ab38e","https://git.kernel.org/stable/c/122e3a7a8c7bcbe3aacddd6103f67f9f36bed473","https://git.kernel.org/stable/c/2495c8e272d84685403506833a664fad932e453a","https://git.kernel.org/stable/c/2f5da549535be8ccd2ab7c9abac8562ad370b181","https://git.kernel.org/stable/c/b3dfa878257a7e98830b3009ca5831a01d8f85fc","https://git.kernel.org/stable/c/b7e99058eb2e86aabd7a10761e76cae33d22b49f","https://git.kernel.org/stable/c/c130a3c09e3746c1a09ce26c20d21d449d039b1d","https://git.kernel.org/stable/c/c6979719012a90e5b8e3bc31725fbfdd0b9b2b79","https://git.kernel.org/stable/c/f5f6d90087131812c1e4b9d3103f400f1624396d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49063 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: arfs: fix use-after-free when freeing @rx_cpu_rmap The CI testing bots triggered the following splat: [ 718.203054] BUG: KASAN: use-after-free in free_irq_cpu_rmap+0x53/0x80 [ 718.206349] Read of size 4 at addr ffff8881bd127e00 by task sh/20834 [ 718.212852] CPU: 28 PID: 20834 Comm: sh Kdump: loaded Tainted: G S W IOE 5.17.0-rc8_nextqueue-devqueue-02643-g23f3121aca93 #1 [ 718.219695] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0012.070720200218 07/07/2020 [ 718.223418] Call Trace: [ 718.227139] [ 718.230783] dump_stack_lvl+0x33/0x42 [ 718.234431] print_address_description.constprop.9+0x21/0x170 [ 718.238177] ? free_irq_cpu_rmap+0x53/0x80 [ 718.241885] ? free_irq_cpu_rmap+0x53/0x80 [ 718.245539] kasan_report.cold.18+0x7f/0x11b [ 718.249197] ? free_irq_cpu_rmap+0x53/0x80 [ 718.252852] free_irq_cpu_rmap+0x53/0x80 [ 718.256471] ice_free_cpu_rx_rmap.part.11+0x37/0x50 [ice] [ 718.260174] ice_remove_arfs+0x5f/0x70 [ice] [ 718.263810] ice_rebuild_arfs+0x3b/0x70 [ice] [ 718.267419] ice_rebuild+0x39c/0xb60 [ice] [ 718.270974] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 718.274472] ? ice_init_phy_user_cfg+0x360/0x360 [ice] [ 718.278033] ? delay_tsc+0x4a/0xb0 [ 718.281513] ? preempt_count_sub+0x14/0xc0 [ 718.284984] ? delay_tsc+0x8f/0xb0 [ 718.288463] ice_do_reset+0x92/0xf0 [ice] [ 718.292014] ice_pci_err_resume+0x91/0xf0 [ice] [ 718.295561] pci_reset_function+0x53/0x80 <...> [ 718.393035] Allocated by task 690: [ 718.433497] Freed by task 20834: [ 718.495688] Last potentially related work creation: [ 718.568966] The buggy address belongs to the object at ffff8881bd127e00 which belongs to the cache kmalloc-96 of size 96 [ 718.574085] The buggy address is located 0 bytes inside of 96-byte region [ffff8881bd127e00, ffff8881bd127e60) [ 718.579265] The buggy address belongs to the page: [ 718.598905] Memory state around the buggy address: [ 718.601809] ffff8881bd127d00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.604796] ffff8881bd127d80: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 718.607794] >ffff8881bd127e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 718.610811] ^ [ 718.613819] ffff8881bd127e80: 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc [ 718.617107] ffff8881bd127f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc This is due to that free_irq_cpu_rmap() is always being called *after* (devm_)free_irq() and thus it tries to work with IRQ descs already freed. For example, on device reset the driver frees the rmap right before allocating a new one (the splat above). Make rmap creation and freeing function symmetrical with {request,free}_irq() calls i.e. do that on ifup/ifdown instead of device probe/remove/resume. These operations can be performed independently from the actual device aRFS configuration. Also, make sure ice_vsi_free_irq() clears IRQ affinity notifiers only when aRFS is disabled -- otherwise, CPU rmap sets and clears its own and they must not be touched manually. | ["https://git.kernel.org/stable/c/618df75f2e30c7838a3e010ca32cd4893ec9fe33","https://git.kernel.org/stable/c/d08d2fb6d99d82da1c63aba5c0d1c6f237e150f3","https://git.kernel.org/stable/c/d7442f512b71fc63a99c8a801422dde4fbbf9f93"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49359 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/panfrost: Job should reference MMU not file_priv For a while now it's been allowed for a MMU context to outlive it's corresponding panfrost_priv, however the job structure still references panfrost_priv to get hold of the MMU context. If panfrost_priv has been freed this is a use-after-free which I've been able to trigger resulting in a splat. To fix this, drop the reference to panfrost_priv in the job structure and add a direct reference to the MMU structure which is what's actually needed. | ["https://git.kernel.org/stable/c/472dd7ea5e19a1aeabf1711ddc756777e05ee7c2","https://git.kernel.org/stable/c/6e516faf04317db2c46cbec4e3b78b4653a5b109","https://git.kernel.org/stable/c/8c8e8cc91a6ffc79865108279a74fd57d9070a17"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49390 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: macsec: fix UAF bug for real_dev Create a new macsec device but not get reference to real_dev. That can not ensure that real_dev is freed after macsec. That will trigger the UAF bug for real_dev as following: ================================================================== BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161 Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748 Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327 After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we can add dev_hold_track() in macsec_dev_init() and dev_put_track() in macsec_free_netdev() to fix the problem. | ["https://git.kernel.org/stable/c/196a888ca6571deb344468e1d7138e3273206335","https://git.kernel.org/stable/c/78933cbc143b82d02330e00900d2fd08f2682f4e","https://git.kernel.org/stable/c/d130282179aa6051449ac8f8df1115769998a665"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49465 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-throttle: Set BIO_THROTTLED when bio has been throttled 1.In current process, all bio will set the BIO_THROTTLED flag after __blk_throtl_bio(). 2.If bio needs to be throttled, it will start the timer and stop submit bio directly. Bio will submit in blk_throtl_dispatch_work_fn() when the timer expires.But in the current process, if bio is throttled. The BIO_THROTTLED will be set to bio after timer start. If the bio has been completed, it may cause use-after-free blow. BUG: KASAN: use-after-free in blk_throtl_bio+0x12f0/0x2c70 Read of size 2 at addr ffff88801b8902d4 by task fio/26380 dump_stack+0x9b/0xce print_address_description.constprop.6+0x3e/0x60 kasan_report.cold.9+0x22/0x3a blk_throtl_bio+0x12f0/0x2c70 submit_bio_checks+0x701/0x1550 submit_bio_noacct+0x83/0xc80 submit_bio+0xa7/0x330 mpage_readahead+0x380/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 26380: kasan_save_stack+0x19/0x40 __kasan_kmalloc.constprop.2+0xc1/0xd0 kmem_cache_alloc+0x146/0x440 mempool_alloc+0x125/0x2f0 bio_alloc_bioset+0x353/0x590 mpage_alloc+0x3b/0x240 do_mpage_readpage+0xddf/0x1ef0 mpage_readahead+0x264/0x500 read_pages+0x1c1/0xbf0 page_cache_ra_unbounded+0x471/0x6f0 do_page_cache_ra+0xda/0x110 ondemand_readahead+0x442/0xae0 page_cache_async_ra+0x210/0x300 generic_file_buffered_read+0x4d9/0x2130 generic_file_read_iter+0x315/0x490 blkdev_read_iter+0x113/0x1b0 aio_read+0x2ad/0x450 io_submit_one+0xc8e/0x1d60 __se_sys_io_submit+0x125/0x350 do_syscall_64+0x2d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Freed by task 0: kasan_save_stack+0x19/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x1b/0x30 __kasan_slab_free+0x111/0x160 kmem_cache_free+0x94/0x460 mempool_free+0xd6/0x320 bio_free+0xe0/0x130 bio_put+0xab/0xe0 bio_endio+0x3a6/0x5d0 blk_update_request+0x590/0x1370 scsi_end_request+0x7d/0x400 scsi_io_completion+0x1aa/0xe50 scsi_softirq_done+0x11b/0x240 blk_mq_complete_request+0xd4/0x120 scsi_mq_done+0xf0/0x200 virtscsi_vq_done+0xbc/0x150 vring_interrupt+0x179/0x390 __handle_irq_event_percpu+0xf7/0x490 handle_irq_event_percpu+0x7b/0x160 handle_irq_event+0xcc/0x170 handle_edge_irq+0x215/0xb20 common_interrupt+0x60/0x120 asm_common_interrupt+0x1e/0x40 Fix this by move BIO_THROTTLED set into the queue_lock. | ["https://git.kernel.org/stable/c/0cfc8a0fb07cde61915e4a77c4794c47de3114a4","https://git.kernel.org/stable/c/5a011f889b4832aa80c2a872a5aade5c48d2756f","https://git.kernel.org/stable/c/935fa666534d7b7185e8c6b0191cd06281be4290"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49471 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtw89: cfo: check mac_id to avoid out-of-bounds Somehow, hardware reports incorrect mac_id and pollute memory. Check index before we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: <IRQ> show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 </IRQ> <TASK> __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> | ["https://git.kernel.org/stable/c/03ed236480aeec8c2fd327a1ea6d711364c495e3","https://git.kernel.org/stable/c/97df85871a5b187609d30fca6d85b912d9e02f29","https://git.kernel.org/stable/c/c32fafe68298bb599e825c298e1d0ba30186f0a5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49535 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference after failing to issue FLOGI and PLOGI If lpfc_issue_els_flogi() fails and returns non-zero status, the node reference count is decremented to trigger the release of the nodelist structure. However, if there is a prior registration or dev-loss-evt work pending, the node may be released prematurely. When dev-loss-evt completes, the released node is referenced causing a use-after-free null pointer dereference. Similarly, when processing non-zero ELS PLOGI completion status in lpfc_cmpl_els_plogi(), the ndlp flags are checked for a transport registration before triggering node removal. If dev-loss-evt work is pending, the node may be released prematurely and a subsequent call to lpfc_dev_loss_tmo_handler() results in a use after free ndlp dereference. Add test for pending dev-loss before decrementing the node reference count for FLOGI, PLOGI, PRLI, and ADISC handling. | ["https://git.kernel.org/stable/c/10663ebec0ad5c78493a0dd34c9ee4d73d7ca0df","https://git.kernel.org/stable/c/577a942df3de2666f6947bdd3a5c9e8d30073424","https://git.kernel.org/stable/c/c7dc74ab7975c9b96284abfe4cca756d75fa4604"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49711 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove() In fsl_mc_bus_remove(), mc->root_mc_bus_dev->mc_io is passed to fsl_destroy_mc_io(). However, mc->root_mc_bus_dev is already freed in fsl_mc_device_remove(). Then reference to mc->root_mc_bus_dev->mc_io triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->root_mc_bus_dev->mc_io in a local variable and pass to fsl_destroy_mc_io(). This patch needs rework to apply to kernels older than v5.15. | ["https://git.kernel.org/stable/c/161b68b0a728377aaa10a8e14c70e7734f3c9ff7","https://git.kernel.org/stable/c/928ea98252ad75118950941683893cf904541da9","https://git.kernel.org/stable/c/ccd1751092341ac120a961835211f9f2e3735963"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49730 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Resolve NULL ptr dereference after an ELS LOGO is aborted A use-after-free crash can occur after an ELS LOGO is aborted. Specifically, a nodelist structure is freed and then ndlp->vport->cfg_log_verbose is dereferenced in lpfc_nlp_get() when the discovery state machine is mistakenly called a second time with NLP_EVT_DEVICE_RM argument. Rework lpfc_cmpl_els_logo() to prevent the duplicate calls to release a nodelist structure. | ["https://git.kernel.org/stable/c/5e83869e29448958f8ae2c6911f350318f75e4fc","https://git.kernel.org/stable/c/b1b3440f437b75fb2a9b0cfe58df461e40eca474","https://git.kernel.org/stable/c/eea34ce23dc3a595695856dc73bb132a9c5a2902"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21714 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix implicit ODP use after free Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr. Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below. refcount_t: underflow; use-after-free. WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130 Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs] CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib] RIP: 0010:refcount_warn_saturate+0x12b/0x130 Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027 RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0 RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019 R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00 R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0 FS: 0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? refcount_warn_saturate+0x12b/0x130 free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib] process_one_work+0x1cc/0x3c0 worker_thread+0x218/0x3c0 kthread+0xc6/0xf0 ret_from_fork+0x1f/0x30 </TASK> | ["https://git.kernel.org/stable/c/7cc8f681f6d4ae4478ae0f60485fc768f2b450da","https://git.kernel.org/stable/c/d3d930411ce390e532470194296658a960887773","https://git.kernel.org/stable/c/edfb65dbb9ffd3102f3ff4dd21316158e56f1976"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21739 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix use-after free in init error and remove paths devm_blk_crypto_profile_init() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufs_hba's data structure 'struct ufs_hba::crypto_profile'. This structure is allocated as part of the underlying ufshcd and therefore Scsi_host allocation. During driver release or during error handling in ufshcd_pltfrm_init(), this structure is released as part of ufshcd_dealloc_host() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufs_hba::crypto_profile'. This causes a use-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0 In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-device and during error handling of ufshcd_pltfrm_init() or during driver removal: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handler To fix this use-after free, change ufshcd_alloc_host() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup | ["https://git.kernel.org/stable/c/0c77c0d754fe83cb154715fcfec6c3faef94f207","https://git.kernel.org/stable/c/9c185beae09a3eb85f54777edafa227f7e03075d","https://git.kernel.org/stable/c/f8fb2403ddebb5eea0033d90d9daae4c88749ada"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21786 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: workqueue: Put the pwq after detaching the rescuer from the pool The commit 68f83057b913("workqueue: Reap workers via kthread_stop() and remove detach_completion") adds code to reap the normal workers but mistakenly does not handle the rescuer and also removes the code waiting for the rescuer in put_unbound_pool(), which caused a use-after-free bug reported by Cheung Wall. To avoid the use-after-free bug, the pool’s reference must be held until the detachment is complete. Therefore, move the code that puts the pwq after detaching the rescuer from the pool. | ["https://git.kernel.org/stable/c/835b69c868f53f959d4986bbecd561ba6f38e492","https://git.kernel.org/stable/c/e76946110137703c16423baf6ee177b751a34b7e","https://git.kernel.org/stable/c/e7c16028a424dd35be1064a68fa318be4359310f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53155 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix uninitialized value in ocfs2_file_read_iter() Syzbot has reported the following KMSAN splat: BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30 Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Since an instance of 'struct kiocb' may be passed from the block layer with 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()' and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in 'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'. | ["https://git.kernel.org/stable/c/366c933c2ab34dd6551acc03b4872726b7605143","https://git.kernel.org/stable/c/66b7ddd1804e2c4216dd7ead8eeb746cdbb3b62f","https://git.kernel.org/stable/c/6c8f8d1e595dabd5389817f6d798cc8bd95c40ab","https://git.kernel.org/stable/c/83f8713a0ef1d55d6a287bcfadcaab8245ac5098","https://git.kernel.org/stable/c/8c966150d5abff58c3c2bdb9a6e63fd773782905","https://git.kernel.org/stable/c/8e0de82ed18ba0e71f817adbd81317fd1032ca5a","https://git.kernel.org/stable/c/adc77b19f62d7e80f98400b2fca9d700d2afdd6f","https://git.kernel.org/stable/c/dc78efe556fed162d48736ef24066f42e463e27c","https://git.kernel.org/stable/c/f4078ef38d3163e6be47403a619558b19c4bfccd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6356 | High | fixed |
|
A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver and causing kernel panic and a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6356","https://bugzilla.redhat.com/show_bug.cgi?id=2254054","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/errata/RHSA-2024:3810","https://access.redhat.com/security/cve/CVE-2023-6356","https://bugzilla.redhat.com/show_bug.cgi?id=2254054","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://security.netapp.com/advisory/ntap-20240415-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53055 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32. | ["https://git.kernel.org/stable/c/2ac15e5a8f42fed5d90ed9e1197600913678c50f","https://git.kernel.org/stable/c/2ccd5badadab2d586e91546bf5af3deda07fef1f","https://git.kernel.org/stable/c/7245012f0f496162dd95d888ed2ceb5a35170f1a","https://git.kernel.org/stable/c/cde8a7eb5c6762264ff0f4433358e0a0d250c875","https://git.kernel.org/stable/c/fc621e7a043de346c33bd7ae7e2e0c651d6152ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21673 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double free of TCP_Server_Info::hostname When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> | ["https://git.kernel.org/stable/c/1ea68070338518a1d31ce71e6abfe1b30001b27a","https://git.kernel.org/stable/c/a2be5f2ba34d0c6d5ef2624b24e3d852561fcd6a","https://git.kernel.org/stable/c/fa2f9906a7b333ba757a7dbae0713d8a5396186e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57834 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/1221989555db711578a327a9367f1be46500cb48","https://git.kernel.org/stable/c/2c5601b99d79d196fe4a37159e3dfb38e778ea18","https://git.kernel.org/stable/c/52d3512f9a7a52ef92864679b1e8e8aa16202c6a","https://git.kernel.org/stable/c/59a707ad952eb2ea8d59457d662b6f4138f17b08","https://git.kernel.org/stable/c/86307e443c5844f38e1b98e2c51a4195c55576cd","https://git.kernel.org/stable/c/904a8323cc8afa7eb9ce3e67303a2b3f2f787306","https://git.kernel.org/stable/c/95432a37778c9c5dd105b7b9f19e9695c9e166cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58005 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). | ["https://git.kernel.org/stable/c/0621d2599d6e02d05c85d6bbd58eaea2f15b3503","https://git.kernel.org/stable/c/422d7f4e8d817be467986589c7968d3ea402f7da","https://git.kernel.org/stable/c/4c8bfe643bbd00b04ee8f9545ef33bf6a68c38db","https://git.kernel.org/stable/c/50365a6304a57266e8f4d3078060743c3b7a1e0d","https://git.kernel.org/stable/c/77779d1258a287f2c5c2c6aeae203e0996209c77","https://git.kernel.org/stable/c/a3a860bc0fd6c07332e4911cf9a238d20de90173","https://git.kernel.org/stable/c/a676c0401de59548a5bc1b7aaf98f556ae8ea6db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58076 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: qcom: gcc-sm6350: Add missing parent_map for two clocks If a clk_rcg2 has a parent, it should also have parent_map defined, otherwise we'll get a NULL pointer dereference when calling clk_set_rate like the following: [ 3.388105] Call trace: [ 3.390664] qcom_find_src_index+0x3c/0x70 (P) [ 3.395301] qcom_find_src_index+0x1c/0x70 (L) [ 3.399934] _freq_tbl_determine_rate+0x48/0x100 [ 3.404753] clk_rcg2_determine_rate+0x1c/0x28 [ 3.409387] clk_core_determine_round_nolock+0x58/0xe4 [ 3.421414] clk_core_round_rate_nolock+0x48/0xfc [ 3.432974] clk_core_round_rate_nolock+0xd0/0xfc [ 3.444483] clk_core_set_rate_nolock+0x8c/0x300 [ 3.455886] clk_set_rate+0x38/0x14c Add the parent_map property for two clocks where it's missing and also un-inline the parent_data as well to keep the matching parent_map and parent_data together. | ["https://git.kernel.org/stable/c/08b77ed7cfaac62bba51ac7a0487409ec9fcbc84","https://git.kernel.org/stable/c/175af15551ed5aa6af16ff97aff75cfffb42da21","https://git.kernel.org/stable/c/39336edd14a59dc086fb19957655e0f340bb28e8","https://git.kernel.org/stable/c/3e567032233a240b903dc11c9f18eeb3faa10ffa","https://git.kernel.org/stable/c/96fe1a7ee477d701cfc98ab9d3c730c35d966861","https://git.kernel.org/stable/c/b6fe13566bf5676b1e3b72d2a06d875733e93ee6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21707 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: consolidate suboption status MPTCP maintains the received sub-options status is the bitmask carrying the received suboptions and in several bitfields carrying per suboption additional info. Zeroing the bitmask before parsing is not enough to ensure a consistent status, and the MPTCP code has to additionally clear some bitfiled depending on the actually parsed suboption. The above schema is fragile, and syzbot managed to trigger a path where a relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated--- | ["https://git.kernel.org/stable/c/3a7fda57b0f91f7ea34476b165f91a92feb17c96","https://git.kernel.org/stable/c/3b5332d416d151a15742d1b16e7319368e3cc5c6","https://git.kernel.org/stable/c/6169e942370b4b6f9442d35c51519bf6c346843b","https://git.kernel.org/stable/c/7f6c72b8ef8130760710e337dc8fbe7263954884","https://git.kernel.org/stable/c/ba0518f9e8688cd4fcb569e8df2a74874b4f3894","https://git.kernel.org/stable/c/c86b000782daba926c627d2fa00c3f60a75e7472"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21711 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/rose: prevent integer overflows in rose_setsockopt() In case of possible unpredictably large arguments passed to rose_setsockopt() and multiplied by extra values on top of that, integer overflows may occur. Do the safest minimum and fix these issues by checking the contents of 'opt' and returning -EINVAL if they are too large. Also, switch to unsigned int and remove useless check for negative 'opt' in ROSE_IDLE case. | ["https://git.kernel.org/stable/c/352daa50946c3bbb662432e8daf54d6760796589","https://git.kernel.org/stable/c/4bdd449977e2364a53d0b2a5427e71beb1cd702d","https://git.kernel.org/stable/c/9bdee49ad6bbd26ab5e13cc6731e54fb1b6c1dca","https://git.kernel.org/stable/c/b8583b54455cbec2fc038fa32b6700890b369815","https://git.kernel.org/stable/c/d08f4074f9c69f7e95502587eb1b258a965ba7f0","https://git.kernel.org/stable/c/d640627663bfe7d8963c7615316d7d4ef60f3b0b","https://git.kernel.org/stable/c/e5338930a29d0ab2a5af402f5f664aeba0d1a676"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21745 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix class @block_class's subsystem refcount leakage blkcg_fill_root_iostats() iterates over @block_class's devices by class_dev_iter_(init|next)(), but does not end iterating with class_dev_iter_exit(), so causes the class's subsystem refcount leakage. Fix by ending the iterating with class_dev_iter_exit(). | ["https://git.kernel.org/stable/c/2ce09aabe009453d641a2ceb79e6461a2d4f3876","https://git.kernel.org/stable/c/38287f779b34dfe959b4b681e909f2d3d52b88be","https://git.kernel.org/stable/c/431b6ef2714be4d5babb802114987541a88b43b0","https://git.kernel.org/stable/c/67c7f213e052b1aa6caba4a7e25e303bc6997126","https://git.kernel.org/stable/c/993121481b5a87829f1e8163f47158b72679f309","https://git.kernel.org/stable/c/d1248436cbef1f924c04255367ff4845ccd9025e","https://git.kernel.org/stable/c/ffb494f1e7a047bd7a41b13796fcfb08fe5beafb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21779 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel Advertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID. Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC. | ["https://git.kernel.org/stable/c/45fa526b0f5a34492ed0536c3cdf88b78380e4de","https://git.kernel.org/stable/c/5393cf22312418262679eaadb130d608c75fe690","https://git.kernel.org/stable/c/61224533f2b61e252b03e214195d27d64b22989a","https://git.kernel.org/stable/c/874ff13c73c45ecb38cb82191e8c1d523f0dc81b","https://git.kernel.org/stable/c/a8de7f100bb5989d9c3627d3a223ee1c863f3b69","https://git.kernel.org/stable/c/aca8be4403fb90db7adaf63830e27ebe787a76e8","https://git.kernel.org/stable/c/ca29f58ca374c40a0e69c5306fc5c940a0069074"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26767 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check | ["https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738","https://git.kernel.org/stable/c/070fda699dfdce560755379bc428d9edada7a54e","https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375","https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7","https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738","https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375","https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27062 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nouveau: lock the client object tree. It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555] <TASK> [ 4562.099573] ? die_addr+0x36/0x90 [ 4562.099583] ? exc_general_protection+0x246/0x4a0 [ 4562.099593] ? asm_exc_general_protection+0x26/0x30 [ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356] __do_fault+0x32/0x150 [ 4562.100362] do_fault+0x7c/0x560 [ 4562.100369] __handle_mm_fault+0x800/0xc10 [ 4562.100382] handle_mm_fault+0x17c/0x3e0 [ 4562.100388] do_user_addr_fault+0x208/0x860 [ 4562.100395] exc_page_fault+0x7f/0x200 [ 4562.100402] asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446] </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated--- | ["https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7","https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589","https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135","https://git.kernel.org/stable/c/6887314f5356389fc219b8152e951ac084a10ef7","https://git.kernel.org/stable/c/96c8751844171af4b3898fee3857ee180586f589","https://git.kernel.org/stable/c/b7cc4ff787a572edf2c55caeffaa88cd801eb135"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35784 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock with fiemap and extent locking While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock. This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it. Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting. Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed. This would deadlock with the following stack trace [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking. To fix this simply don't take the extent lock for the entire duration of the fiemap. This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before. The only place we maintain the lock is searching delalloc. Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag. With this patch applied we no longer deadlock with my testcase. | ["https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b","https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd","https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf","https://git.kernel.org/stable/c/89bca7fe6382d61e88c67a0b0e7bce315986fb8b","https://git.kernel.org/stable/c/b0ad381fa7690244802aed119b478b4bdafc31dd","https://git.kernel.org/stable/c/ded566b4637f1b6b4c9ba74e7d0b8493e93f19cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57996 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net_sched: sch_sfq: don't allow 1 packet limit The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well. This fixes the following syzkaller reported crash: UBSAN: array-index-out-of-bounds in net/sched/sch_sfq.c:210:6 index 65535 is out of range for type 'struct sfq_head[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x125/0x19f lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_out_of_bounds+0xed/0x120 lib/ubsan.c:347 sfq_link net/sched/sch_sfq.c:210 [inline] sfq_dec+0x528/0x600 net/sched/sch_sfq.c:238 sfq_dequeue+0x39b/0x9d0 net/sched/sch_sfq.c:500 sfq_reset+0x13/0x50 net/sched/sch_sfq.c:525 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 tbf_reset+0x3d/0x100 net/sched/sch_tbf.c:319 qdisc_reset+0xfe/0x510 net/sched/sch_generic.c:1026 dev_reset_queue+0x8c/0x140 net/sched/sch_generic.c:1296 netdev_for_each_tx_queue include/linux/netdevice.h:2350 [inline] dev_deactivate_many+0x6dc/0xc20 net/sched/sch_generic.c:1362 __dev_close_many+0x214/0x350 net/core/dev.c:1468 dev_close_many+0x207/0x510 net/core/dev.c:1506 unregister_netdevice_many+0x40f/0x16b0 net/core/dev.c:10738 unregister_netdevice_queue+0x2be/0x310 net/core/dev.c:10695 unregister_netdevice include/linux/netdevice.h:2893 [inline] __tun_detach+0x6b6/0x1600 drivers/net/tun.c:689 tun_detach drivers/net/tun.c:705 [inline] tun_chr_close+0x104/0x1b0 drivers/net/tun.c:3640 __fput+0x203/0x840 fs/file_table.c:280 task_work_run+0x129/0x1b0 kernel/task_work.c:185 exit_task_work include/linux/task_work.h:33 [inline] do_exit+0x5ce/0x2200 kernel/exit.c:931 do_group_exit+0x144/0x310 kernel/exit.c:1046 __do_sys_exit_group kernel/exit.c:1057 [inline] __se_sys_exit_group kernel/exit.c:1055 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:1055 do_syscall_64+0x6c/0xd0 entry_SYSCALL_64_after_hwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. | ["https://git.kernel.org/stable/c/10685681bafce6febb39770f3387621bf5d67d0b","https://git.kernel.org/stable/c/35d0137305ae2f97260a9047f445bd4434bd6cc7","https://git.kernel.org/stable/c/7d8947f2153ee9c5ab4cb17861a11cc45f30e8c4","https://git.kernel.org/stable/c/7fefc294204f10a3405f175f4ac2be16d63f135e","https://git.kernel.org/stable/c/833e9a1c27b82024db7ff5038a51651f48f05e5e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47704 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. | ["https://git.kernel.org/stable/c/0508a4e95ac1aefd851ceb97ea050d8abb93262c","https://git.kernel.org/stable/c/0beca868cde8742240cd0038141c30482d2b7eb8","https://git.kernel.org/stable/c/530e29452b955c30cf2102fa4d07420dc6e0c953","https://git.kernel.org/stable/c/be2ca7a2c1561390d28bf2f92654d819659ba510"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/ | ["https://git.kernel.org/stable/c/16007768551d5bfe53426645401435ca8d2ef54f","https://git.kernel.org/stable/c/9288a9676c529ad9c856096db68fad812499bc4a","https://git.kernel.org/stable/c/9773737375b20070ea935203fd66cb9fa17c5acb","https://git.kernel.org/stable/c/e8ac2060597a5768e4699bb61d604b4c09927b85"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49919 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010) | ["https://git.kernel.org/stable/c/16ce8fd94da8599bb6f0496895d392a69aead1c0","https://git.kernel.org/stable/c/390d757621f5f35d11a63ed7d9d3262ead240064","https://git.kernel.org/stable/c/8a1b1655a490a492a5a6987254c935ecce4eb9de","https://git.kernel.org/stable/c/f22f4754aaa47d8c59f166ba3042182859e5dff7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49923 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity. | ["https://git.kernel.org/stable/c/39a580cd15397e102aaec25986ae5acf492f8930","https://git.kernel.org/stable/c/5559598742fb4538e4c51c48ef70563c49c2af23","https://git.kernel.org/stable/c/85aa996ecfaa95d1e922867390502d23ce21b905","https://git.kernel.org/stable/c/9a05270869f40c89f8d184fe2d37cb86e0d7e5f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49926 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 </TASK> Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ] | ["https://git.kernel.org/stable/c/05095271a4fb0f6497121a057f9a2edf386d5d96","https://git.kernel.org/stable/c/3104bddc666ff64b90491868bbc4c7ebdd90aedf","https://git.kernel.org/stable/c/b3b2431ed27f4ebc28e26cdf005c1de42dc60bdf","https://git.kernel.org/stable/c/fd70e9f1d85f5323096ad313ba73f5fe3d15ea41"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49987 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer. | ["https://git.kernel.org/stable/c/2e0f6f33f2aa87493b365a38a8fd87b8854b7734","https://git.kernel.org/stable/c/c208b02827eb642758cef65641995fd3f38c89af","https://git.kernel.org/stable/c/c2d9f9a7837ab29ccae0c42252f17d436bf0a501","https://git.kernel.org/stable/c/f04e2ad394e2755d0bb2d858ecb5598718bf00d5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49988 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used. | ["https://git.kernel.org/stable/c/18f06bacc197d4ac9b518ad1c69999bc3d83e7aa","https://git.kernel.org/stable/c/9fd3cde4628bcd3549ab95061f2bab74d2ed4f3b","https://git.kernel.org/stable/c/e9dac92f4482a382e8c0fe1bc243da5fc3526b0c","https://git.kernel.org/stable/c/ee426bfb9d09b29987369b897fe9b6485ac2be27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-43098 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i3c: Use i3cdev->desc->info instead of calling i3c_device_get_info() to avoid deadlock A deadlock may happen since the i3c_master_register() acquires &i3cbus->lock twice. See the log below. Use i3cdev->desc->info instead of calling i3c_device_info() to avoid acquiring the lock twice. v2: - Modified the title and commit message ============================================ WARNING: possible recursive locking detected 6.11.0-mainline -------------------------------------------- init/1 is trying to acquire lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_bus_normaluse_lock but task is already holding lock: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&i3cbus->lock); lock(&i3cbus->lock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by init/1: #0: fcffff809b6798f8 (&dev->mutex){....}-{3:3}, at: __driver_attach #1: f1ffff80a6a40dc0 (&i3cbus->lock){++++}-{3:3}, at: i3c_master_register stack backtrace: CPU: 6 UID: 0 PID: 1 Comm: init Call trace: dump_backtrace+0xfc/0x17c show_stack+0x18/0x28 dump_stack_lvl+0x40/0xc0 dump_stack+0x18/0x24 print_deadlock_bug+0x388/0x390 __lock_acquire+0x18bc/0x32ec lock_acquire+0x134/0x2b0 down_read+0x50/0x19c i3c_bus_normaluse_lock+0x14/0x24 i3c_device_get_info+0x24/0x58 i3c_device_uevent+0x34/0xa4 dev_uevent+0x310/0x384 kobject_uevent_env+0x244/0x414 kobject_uevent+0x14/0x20 device_add+0x278/0x460 device_register+0x20/0x34 i3c_master_register_new_i3c_devs+0x78/0x154 i3c_master_register+0x6a0/0x6d4 mtk_i3c_master_probe+0x3b8/0x4d8 platform_probe+0xa0/0xe0 really_probe+0x114/0x454 __driver_probe_device+0xa0/0x15c driver_probe_device+0x3c/0x1ac __driver_attach+0xc4/0x1f0 bus_for_each_dev+0x104/0x160 driver_attach+0x24/0x34 bus_add_driver+0x14c/0x294 driver_register+0x68/0x104 __platform_driver_register+0x20/0x30 init_module+0x20/0xfe4 do_one_initcall+0x184/0x464 do_init_module+0x58/0x1ec load_module+0xefc/0x10c8 __arm64_sys_finit_module+0x238/0x33c invoke_syscall+0x58/0x10c el0_svc_common+0xa8/0xdc do_el0_svc+0x1c/0x28 el0_svc+0x50/0xac el0t_64_sync_handler+0x70/0xbc el0t_64_sync+0x1a8/0x1ac | ["https://git.kernel.org/stable/c/1f51ae217d09c361ede900b94735a6d2df6c0344","https://git.kernel.org/stable/c/2d98fa2a50b8058de52ada168fa5dbabb574711b","https://git.kernel.org/stable/c/5ac1dd51aaa0ce8b5421d1137e857955a4b6f55e","https://git.kernel.org/stable/c/6cf7b65f7029914dc0cd7db86fac9ee5159008c6","https://git.kernel.org/stable/c/816187b1833908941286e71b0041059a4acd52ed","https://git.kernel.org/stable/c/9a2173660ee53d5699744f02e6ab7bf89fcd0b1a","https://git.kernel.org/stable/c/ffe19e363c6f8b992ba835a361542568dea17409"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47143 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma-debug: fix a possible deadlock on radix_lock radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock(): CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock() CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd(). CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends). To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap(). | ["https://git.kernel.org/stable/c/3ccce34a5c3f5c9541108a451657ade621524b32","https://git.kernel.org/stable/c/7543c3e3b9b88212fcd0aaf5cab5588797bdc7de","https://git.kernel.org/stable/c/8c1b4fea8d62285f5e1a8194889b39661608bd8a","https://git.kernel.org/stable/c/c212d91070beca0d03fef7bf988baf4ff4b3eee4","https://git.kernel.org/stable/c/efe1b9bbf356357fdff0399af361133d6e3ba18e","https://git.kernel.org/stable/c/f2b95248a16c5186d1c658fc0aeb2f3bd95e5259"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57946 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: don't keep queue frozen during system suspend Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's PM callbacks. And the motivation is to drain inflight IOs before suspending. block layer's queue freeze looks very handy, but it is also easy to cause deadlock, such as, any attempt to call into bio_queue_enter() may run into deadlock if the queue is frozen in current context. There are all kinds of ->suspend() called in suspend context, so keeping queue frozen in the whole suspend context isn't one good idea. And Marek reported lockdep warning[1] caused by virtio-blk's freeze queue in virtblk_freeze(). [1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/ Given the motivation is to drain in-flight IOs, it can be done by calling freeze & unfreeze, meantime restore to previous behavior by keeping queue quiesced during suspend. | ["https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea","https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4","https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37","https://git.kernel.org/stable/c/92d5139b91147ab372a17daf5dc27a5b9278e516","https://git.kernel.org/stable/c/9ca428c6397abaa8c38f5c69133a2299e1efbbf2","https://git.kernel.org/stable/c/9e323f856cf4963120e0e3892a84ef8bd764a0e4","https://git.kernel.org/stable/c/d738f3215bb4f88911ff4579780a44960c8e0ca5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44931 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: prevent potential speculation leaks in gpio_device_get_desc() Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc(). This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks. This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc. | ["https://git.kernel.org/stable/c/18504710442671b02d00e6db9804a0ad26c5a479","https://git.kernel.org/stable/c/1b955f786a4bcde8c0ccb2b7d519def2acb6f3cc","https://git.kernel.org/stable/c/672c19165fc96dfad531a5458e0b3cdab414aae4","https://git.kernel.org/stable/c/9ae2d8e75b741dbcb0da374753f972410e83b5f3","https://git.kernel.org/stable/c/9d682e89c44bd5819b01f3fbb45a8e3681a4b6d0","https://git.kernel.org/stable/c/c65ab97efcd438cb4e9f299400f2ea55251f3a67","https://git.kernel.org/stable/c/d776c0486b03a5c4afca65b8ff44573592bf93bb","https://git.kernel.org/stable/c/d795848ecce24a75dfd46481aee066ae6fe39775"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46809 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check BIOS images before it is used BIOS images may fail to load and null checks are added before they are used. This fixes 6 NULL_RETURNS issues reported by Coverity. | ["https://git.kernel.org/stable/c/4fcd903a5d9e897420d7d8b3ca55c6e5dbb47379","https://git.kernel.org/stable/c/8b0ddf19cca2a352b2a7e01d99d3ba949a99c84c","https://git.kernel.org/stable/c/c5cb98554c4c6265b494d040c1c62f1db2fa28a6","https://git.kernel.org/stable/c/e46b70a7cfed71cb84e985c785c39c16df5c28cb","https://git.kernel.org/stable/c/e50bec62acaeec03afc6fa5dfb2426e52d049cf5","https://git.kernel.org/stable/c/eef7301e674438913134539e77dd887960949f20"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46822 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry In a review discussion of the changes to support vCPU hotplug where a check was added on the GICC being enabled if was online, it was noted that there is need to map back to the cpu and use that to index into a cpumask. As such, a valid ID is needed. If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible for the entry in cpu_madt_gicc[cpu] == NULL. This function would then cause a NULL pointer dereference. Whilst a path to trigger this has not been established, harden this caller against the possibility. | ["https://git.kernel.org/stable/c/2488444274c70038eb6b686cba5f1ce48ebb9cdd","https://git.kernel.org/stable/c/40cae0df42e5e7f7a1c0f32deed9c4027c1ba94e","https://git.kernel.org/stable/c/4c3b21204abb4fa3ab310fbbb5cf7f0e85f3a1bc","https://git.kernel.org/stable/c/62ca6d3a905b4c40cd942f3cc645a6718f8bc7e7","https://git.kernel.org/stable/c/945be49f4e832a9184c313fdf8917475438a795b","https://git.kernel.org/stable/c/bc7fbb37e3d2df59336eadbd6a56be632e3c7df7","https://git.kernel.org/stable/c/f57769ff6fa7f97f1296965f20e8a2bb3ee9fd0f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46832 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: MIPS: cevt-r4k: Don't call get_c0_compare_int if timer irq is installed This avoids warning: [ 0.118053] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 Caused by get_c0_compare_int on secondary CPU. We also skipped saving IRQ number to struct clock_event_device *cd as it's never used by clockevent core, as per comments it's only meant for "non CPU local devices". | ["https://git.kernel.org/stable/c/189d3ed3b25beee26ffe2abed278208bece13f52","https://git.kernel.org/stable/c/32ee0520159f1e8c2d6597c19690df452c528f30","https://git.kernel.org/stable/c/50f2b98dc83de7809a5c5bf0ccf9af2e75c37c13","https://git.kernel.org/stable/c/b1d2051373bfc65371ce4ac8911ed984d0178c98","https://git.kernel.org/stable/c/d3ff0f98a52f0aafe35aa314d1c442f4318be3db","https://git.kernel.org/stable/c/e6cd871627abbb459d0ff6521d6bb9cf9d9f7522"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46840 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: clean up our handling of refs == 0 in snapshot delete In reada we BUG_ON(refs == 0), which could be unkind since we aren't holding a lock on the extent leaf and thus could get a transient incorrect answer. In walk_down_proc we also BUG_ON(refs == 0), which could happen if we have extent tree corruption. Change that to return -EUCLEAN. In do_walk_down() we catch this case and handle it correctly, however we return -EIO, which -EUCLEAN is a more appropriate error code. Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convert that to proper error handling. Also adjust the error message so we can actually do something with the information. | ["https://git.kernel.org/stable/c/03804641ec2d0da4fa088ad21c88e703d151ce16","https://git.kernel.org/stable/c/71291aa7246645ef622621934d2067400380645e","https://git.kernel.org/stable/c/728d4d045b628e006b48a448f3326a7194c88d32","https://git.kernel.org/stable/c/7d1df13bf078ffebfedd361d714ff6cee1ff01b9","https://git.kernel.org/stable/c/9cc887ac24b7a0598f4042ae9af6b9a33072f75b","https://git.kernel.org/stable/c/b8ccef048354074a548f108e51d0557d6adfd3a3","https://git.kernel.org/stable/c/c60676b81fab456b672796830f6d8057058f029c","https://git.kernel.org/stable/c/c847b28a799733b04574060ab9d00f215970627d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42079 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush). | ["https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce","https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828","https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef","https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce","https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828","https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50148 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: bnep: fix wild-memory-access in proto_unregister There's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: <TASK> __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f As bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init() will cleanup all resource. Then when remove bnep module will call bnep_sock_cleanup() to cleanup sock's resource. To solve above issue just return bnep_sock_init()'s return value in bnep_exit(). | ["https://git.kernel.org/stable/c/03015b6329e6de42f03ec917c25c4cf944f81f66","https://git.kernel.org/stable/c/20c424bc475b2b2a6e0e2225d2aae095c2ab2f41","https://git.kernel.org/stable/c/2c439470b23d78095a0d2f923342df58b155f669","https://git.kernel.org/stable/c/64a90991ba8d4e32e3173ddd83d0b24167a5668c","https://git.kernel.org/stable/c/6c151aeb6dc414db8f4daf51be072e802fae6667","https://git.kernel.org/stable/c/d10cd7bf574ead01fae140ce117a11bcdacbe6a8","https://git.kernel.org/stable/c/e232728242c4e98fb30e4c6bedb6ba8b482b6301","https://git.kernel.org/stable/c/fa58e23ea1359bd24b323916d191e2e9b4b19783"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50168 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sun3_82586: fix potential memory leak in sun3_82586_send_packet() The sun3_82586_send_packet() returns NETDEV_TX_OK without freeing skb in case of skb->len being too long, add dev_kfree_skb() to fix it. | ["https://git.kernel.org/stable/c/137010d26dc5cd47cd62fef77cbe952d31951b7a","https://git.kernel.org/stable/c/1a17a4ac2d57102497fac53b53c666dba6a0c20d","https://git.kernel.org/stable/c/2cb3f56e827abb22c4168ad0c1bbbf401bb2f3b8","https://git.kernel.org/stable/c/6dc937a3086e344f965ca5c459f8f3eb6b68d890","https://git.kernel.org/stable/c/84f2bac74000dbb7a177d9b98a17031ec8d07ec5","https://git.kernel.org/stable/c/8d5b20fbc548650019afa96822b6a33ea4ec8aa5","https://git.kernel.org/stable/c/9c6ce55e6f0bd1541f112833006b4052614c7d94","https://git.kernel.org/stable/c/db755e55349045375c5c7036e8650afb3ff419d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50171 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: systemport: fix potential memory leak in bcm_sysport_xmit() The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skb in case of dma_map_single() fails, add dev_kfree_skb() to fix it. | ["https://git.kernel.org/stable/c/31701ef0c4547973991ff63596c927f841dfd133","https://git.kernel.org/stable/c/4b70478b984af3c9d0279c121df5ff94e2533dbd","https://git.kernel.org/stable/c/533d2f30aef272dade17870a509521c3afc38a03","https://git.kernel.org/stable/c/5febfc545389805ce83d37f9f4317055b26dd7d7","https://git.kernel.org/stable/c/7d5030a819c3589cf9948b1eee397b626ec590f5","https://git.kernel.org/stable/c/8e81ce7d0166a2249deb6d5e42f28a8b8c9ea72f","https://git.kernel.org/stable/c/b6321146773dcbbc372a54dbada67e0b50e0a25c","https://git.kernel.org/stable/c/c401ed1c709948e57945485088413e1bb5e94bd1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53101 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0. | ["https://git.kernel.org/stable/c/15f34347481648a567db67fb473c23befb796af5","https://git.kernel.org/stable/c/17ecb40c5cc7755a321fb6148cba5797431ee5b8","https://git.kernel.org/stable/c/1c28bca1256aecece6e94b26b85cd07e08b0dc90","https://git.kernel.org/stable/c/1cb5bfc5bfc651982b6203c224d49b7ddacf28bc","https://git.kernel.org/stable/c/5a72b0d3497b818d8f000c347a7c11801eb27bfc","https://git.kernel.org/stable/c/9db25c2b41c34963c3ccf473b08171f87670652e","https://git.kernel.org/stable/c/a0c77e5e3dcbffc7c6080ccc89c037f0c86496cf","https://git.kernel.org/stable/c/b3e612bd8f64ce62e731e95f635e06a2efe3c80c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48808 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix panic when DSA master device unbinds on shutdown Rafael reports that on a system with LX2160A and Marvell DSA switches, if a reboot occurs while the DSA master (dpaa2-eth) is up, the following panic can be seen: systemd-shutdown[1]: Rebooting. Unable to handle kernel paging request at virtual address 00a0000800000041 [00a0000800000041] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32 pc : dsa_slave_netdevice_event+0x130/0x3e4 lr : raw_notifier_call_chain+0x50/0x6c Call trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c It can be seen from the stack trace that the problem is that the deregistration of the master causes a dev_close(), which gets notified as NETDEV_GOING_DOWN to dsa_slave_netdevice_event(). But dsa_switch_shutdown() has already run, and this has unregistered the DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to call dev_close_many() on those slave interfaces, leading to the problem. The previous attempt to avoid the NETDEV_GOING_DOWN on the master after dsa_switch_shutdown() was called seems improper. Unregistering the slave interfaces is unnecessary and unhelpful. Instead, after the slaves have stopped being uppers of the DSA master, we can now reset to NULL the master->dsa_ptr pointer, which will make DSA start ignoring all future notifier events on the master. | ["https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7","https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae","https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5","https://git.kernel.org/stable/c/89b60402d43cdab4387dbbf24afebda5cf092ae7","https://git.kernel.org/stable/c/ee534378f00561207656663d93907583958339ae","https://git.kernel.org/stable/c/ff45899e732e57088985e3a497b1d9100571c0f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48846 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: release rq qos structures for queue without disk blkcg_init_queue() may add rq qos structures to request queue, previously blk_cleanup_queue() calls rq_qos_exit() to release them, but commit 8e141f9eb803 ("block: drain file system I/O on del_gendisk") moves rq_qos_exit() into del_gendisk(), so memory leak is caused because queues may not have disk, such as un-present scsi luns, nvme admin queue, ... Fixes the issue by adding rq_qos_exit() to blk_cleanup_queue() back. BTW, v5.18 won't need this patch any more since we move blkcg_init_queue()/blkcg_exit_queue() into disk allocation/release handler, and patches have been in for-5.18/block. | ["https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29","https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e","https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b","https://git.kernel.org/stable/c/60c2c8e2ef3a3ec79de8cbc80a06ca0c21df8c29","https://git.kernel.org/stable/c/d4ad8736ac982111bb0be8306bf19c8207f6600e","https://git.kernel.org/stable/c/daaca3522a8e67c46e39ef09c1d542e866f85f3b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6932 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation. A race condition can be exploited to cause a timer be mistakenly registered on a RCU read locked object which is freed by another thread. We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1. | ["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1","https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=e2b706c691905fe78468c361aaabc719d0a496f1","https://kernel.dance/e2b706c691905fe78468c361aaabc719d0a496f1","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42229 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: aead,cipher - zeroize key buffer after use I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding cryptographic information should be zeroized once they are no longer needed. Accomplish this by using kfree_sensitive for buffers that previously held the private key. | ["https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210","https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534","https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d","https://git.kernel.org/stable/c/89b9b6fa4463daf820e6a5ef65c3b0c2db239513","https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133","https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb","https://git.kernel.org/stable/c/b716e9c3603ee95ed45e938fe47227d22cf3ec35","https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e","https://git.kernel.org/stable/c/23e4099bdc3c8381992f9eb975c79196d6755210","https://git.kernel.org/stable/c/28c8d274848feba552e95c5c2a7e3cfe8f15c534","https://git.kernel.org/stable/c/71dd428615375e36523f4d4f7685ddd54113646d","https://git.kernel.org/stable/c/9db8c299a521813630fcb4154298cb60c37f3133","https://git.kernel.org/stable/c/b502d4a08875ea2b4ea5d5b28dc7c991c8b90cfb","https://git.kernel.org/stable/c/f58679996a831754a356974376f248aa0af2eb8e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47636 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix read out-of-bounds in ubifs_wbuf_write_nolock() Function ubifs_wbuf_write_nolock() may access buf out of bounds in following process: ubifs_wbuf_write_nolock(): aligned_len = ALIGN(len, 8); // Assume len = 4089, aligned_len = 4096 if (aligned_len <= wbuf->avail) ... // Not satisfy if (wbuf->used) { ubifs_leb_write() // Fill some data in avail wbuf len -= wbuf->avail; // len is still not 8-bytes aligned aligned_len -= wbuf->avail; } n = aligned_len >> c->max_write_shift; if (n) { n <<= c->max_write_shift; err = ubifs_leb_write(c, wbuf->lnum, buf + written, wbuf->offs, n); // n > len, read out of bounds less than 8(n-len) bytes } , which can be catched by KASAN: ========================================================= BUG: KASAN: slab-out-of-bounds in ecc_sw_hamming_calculate+0x1dc/0x7d0 Read of size 4 at addr ffff888105594ff8 by task kworker/u8:4/128 Workqueue: writeback wb_workfn (flush-ubifs_0_0) Call Trace: kasan_report.cold+0x81/0x165 nand_write_page_swecc+0xa9/0x160 ubifs_leb_write+0xf2/0x1b0 [ubifs] ubifs_wbuf_write_nolock+0x421/0x12c0 [ubifs] write_head+0xdc/0x1c0 [ubifs] ubifs_jnl_write_inode+0x627/0x960 [ubifs] wb_workfn+0x8af/0xb80 Function ubifs_wbuf_write_nolock() accepts that parameter 'len' is not 8 bytes aligned, the 'len' represents the true length of buf (which is allocated in 'ubifs_jnl_xxx', eg. ubifs_jnl_write_inode), so ubifs_wbuf_write_nolock() must handle the length read from 'buf' carefully to write leb safely. Fetch a reproducer in [Link]. | ["https://git.kernel.org/stable/c/07a209fadee7b53b46858538e1177597273862e4","https://git.kernel.org/stable/c/3b7fb89135a20587d57f8877c02e25003e9edbdf","https://git.kernel.org/stable/c/4f2262a334641e05f645364d5ade1f565c85f20b","https://git.kernel.org/stable/c/5343575aa11c5d7044107d59d43f84aec01312b0","https://git.kernel.org/stable/c/a7054aaf1909cf40489c0ec1b728fdcf79c751a6","https://git.kernel.org/stable/c/b80ccbec0e4804436c382d7dd60e943c386ed83a","https://git.kernel.org/stable/c/e09fa5318d51f522e1af4fbaf8f74999355980c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49551 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: isp1760: Fix out-of-bounds array access Running the driver through kasan gives an interesting splat: BUG: KASAN: global-out-of-bounds in isp1760_register+0x180/0x70c Read of size 20 at addr f1db2e64 by task swapper/0/1 (...) isp1760_register from isp1760_plat_probe+0x1d8/0x220 (...) This happens because the loop reading the regmap fields for the different ISP1760 variants look like this: for (i = 0; i < HC_FIELD_MAX; i++) { ... } Meaning it expects the arrays to be at least HC_FIELD_MAX - 1 long. However the arrays isp1760_hc_reg_fields[], isp1763_hc_reg_fields[], isp1763_hc_volatile_ranges[] and isp1763_dc_volatile_ranges[] are dynamically sized during compilation. Fix this by putting an empty assignment to the [HC_FIELD_MAX] and [DC_FIELD_MAX] array member at the end of each array. This will make the array one member longer than it needs to be, but avoids the risk of overwriting whatever is inside [HC_FIELD_MAX - 1] and is simple and intuitive to read. Also add comments explaining what is going on. | ["https://git.kernel.org/stable/c/26ae2c942b5702f2e43d36b2a4389cfb7d616b6a","https://git.kernel.org/stable/c/463bddd3ff1acf4036ddb80c34a715eb99debf46","https://git.kernel.org/stable/c/47d39cb57e8669e507d17d9e0d067d2b3e3a87ae","https://git.kernel.org/stable/c/bf2558bbdce3ab1d6bcba09f354914e4515d0a2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49623 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive/spapr: correct bitmap allocation size kasan detects access beyond the end of the xibm->bitmap allocation: BUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140 Read of size 8 at addr c00000001d1d0118 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28 Call Trace: [c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable) [c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710 [c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354 [c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0 [c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140 [c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260 [c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450 [c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118 [c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac [c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640 [c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0 [c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64 Allocated by task 0: kasan_save_stack+0x34/0x70 __kasan_kmalloc+0xb4/0xf0 __kmalloc+0x268/0x540 xive_spapr_init+0x4d0/0x77c pseries_init_irq+0x40/0x27c init_IRQ+0x44/0x84 start_kernel+0x2a4/0x538 start_here_common+0x1c/0x20 The buggy address belongs to the object at c00000001d1d0118 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of 8-byte region [c00000001d1d0118, c00000001d1d0120) The buggy address belongs to the physical page: page:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d flags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff) raw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480 raw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc >c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc ^ c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc This happens because the allocation uses the wrong unit (bits) when it should pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small numbers of bits, the allocated object can be smaller than sizeof(long), which results in invalid accesses. Use bitmap_zalloc() to allocate and initialize the irq bitmap, paired with bitmap_free() for consistency. | ["https://git.kernel.org/stable/c/10f2cd373e65bcd3be8f3cdc71c330c25763dfd8","https://git.kernel.org/stable/c/19fc5bb93c6bbdce8292b4d7eed04e2fa118d2fe","https://git.kernel.org/stable/c/99d1c36bddd93919072b5a51a89297bbb5ad6a6f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57982 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xfrm: state: fix out-of-bounds read during lookup lookup and resize can run in parallel. The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array. rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask; While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) { This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again). Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent. The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side. xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch. | ["https://git.kernel.org/stable/c/a16871c7832ea6435abb6e0b58289ae7dcb7e4fc","https://git.kernel.org/stable/c/dd4c2a174994238d55ab54da2545543d36f4e0d0","https://git.kernel.org/stable/c/e952837f3ddb0ff726d5b582aa1aad9aa38d024d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26865 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rds: tcp: Fix use-after-free of net in reqsk_timer_handler(). syzkaller reported a warning of netns tracker [0] followed by KASAN splat [1] and another ref tracker warning [1]. syzkaller could not find a repro, but in the log, the only suspicious sequence was as follows: 18:26:22 executing program 1: r0 = socket$inet6_mptcp(0xa, 0x1, 0x106) ... connect$inet6(r0, &(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async) The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT. So, the scenario would be: 1. unshare(CLONE_NEWNET) creates a per netns tcp listener in rds_tcp_listen_init(). 2. syz-executor connect()s to it and creates a reqsk. 3. syz-executor exit()s immediately. 4. netns is dismantled. [0] 5. reqsk timer is fired, and UAF happens while freeing reqsk. [1] 6. listener is freed after RCU grace period. [2] Basically, reqsk assumes that the listener guarantees netns safety until all reqsk timers are expired by holding the listener's refcount. However, this was not the case for kernel sockets. Commit 740ea3c4a0b2 ("tcp: Clean up kernel listener's reqsk in inet_twsk_purge()") fixed this issue only for per-netns ehash. Let's apply the same fix for the global ehash. [0]: ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146) inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119) __sock_create (net/socket.c:1572) rds_tcp_listen_init (net/rds/tcp_listen.c:279) rds_tcp_init_net (net/rds/tcp.c:577) ops_init (net/core/net_namespace.c:137) setup_net (net/core/net_namespace.c:340) copy_net_ns (net/core/net_namespace.c:497) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4)) ksys_unshare (kernel/fork.c:3429) __x64_sys_unshare (kernel/fork.c:3496) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) ... WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) [1]: BUG: KASAN: slab-use-after-free in inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) Read of size 8 at addr ffff88801b370400 by task swapper/0/0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) print_report (mm/kasan/report.c:378 mm/kasan/report.c:488) kasan_report (mm/kasan/report.c:603) inet_csk_reqsk_queue_drop (./include/net/inet_hashtables.h:180 net/ipv4/inet_connection_sock.c:952 net/ipv4/inet_connection_sock.c:966) reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038) run_timer_softirq (kernel/time/timer.c:2053) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14)) </IRQ> Allocated by task 258 on cpu 0 at 83.612050s: kasan_save_stack (mm/kasan/common.c:48) kasan_save_track (mm/kasan/common.c:68) __kasan_slab_alloc (mm/kasan/common.c:343) kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867) copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480) create_new_namespaces (kernel/nsproxy.c:110) unshare_nsproxy_name ---truncated--- | ["https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3","https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24","https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6","https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500","https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279","https://git.kernel.org/stable/c/1e9fd5cf8d7f487332560f7bb312fc7d416817f3","https://git.kernel.org/stable/c/2a750d6a5b365265dbda33330a6188547ddb5c24","https://git.kernel.org/stable/c/9905a157048f441f1412e7bd13372f4a971d75c6","https://git.kernel.org/stable/c/9ceac040506a05a30b104b2aa2e9146810704500","https://git.kernel.org/stable/c/f901ee07853ce97e9f1104c7c898fbbe447f0279"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47656 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix use-after-free in jffs2_clear_xattr_subsystem When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2_scan_eraseblock(). jffs2_clear_xattr_subsystem() is then called in jffs2_build_filesystem() and then again in jffs2_do_fill_super(). Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2_clear_xattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719 Call Trace: dump_stack+0x115/0x16b jffs2_clear_xattr_subsystem+0x95/0x6ac jffs2_do_fill_super+0x84f/0xc30 jffs2_fill_super+0x2ea/0x4c0 mtd_get_sb+0x254/0x400 mtd_get_sb_by_nr+0x4f/0xd0 get_tree_mtd+0x498/0x840 jffs2_get_tree+0x25/0x30 vfs_get_tree+0x8d/0x2e0 path_mount+0x50f/0x1e50 do_mount+0x107/0x130 __se_sys_mount+0x1c5/0x2f0 __x64_sys_mount+0xc7/0x160 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Allocated by task 719: kasan_save_stack+0x23/0x60 __kasan_kmalloc.constprop.0+0x10b/0x120 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0x1c0/0x870 jffs2_alloc_xattr_ref+0x2f/0xa0 jffs2_scan_medium.cold+0x3713/0x4794 jffs2_do_mount_fs.cold+0xa7/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] Freed by task 719: kmem_cache_free+0xcc/0x7b0 jffs2_free_xattr_ref+0x78/0x98 jffs2_clear_xattr_subsystem+0xa1/0x6ac jffs2_do_mount_fs.cold+0x5e6/0x2253 jffs2_do_fill_super+0x383/0xc30 jffs2_fill_super+0x2ea/0x4c0 [...] The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2_xattr_ref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ================================================================== The triggering of the BUG is shown in the following stack: ----------------------------------------------------------- jffs2_fill_super jffs2_do_fill_super jffs2_do_mount_fs jffs2_build_filesystem jffs2_scan_medium jffs2_scan_eraseblock <--- ERROR jffs2_clear_xattr_subsystem <--- free jffs2_clear_xattr_subsystem <--- free again ----------------------------------------------------------- An error is returned in jffs2_do_mount_fs(). If the error is returned by jffs2_sum_init(), the jffs2_clear_xattr_subsystem() does not need to be executed. If the error is returned by jffs2_build_filesystem(), the jffs2_clear_xattr_subsystem() also does not need to be executed again. So move jffs2_clear_xattr_subsystem() from 'out_inohash' to 'out_root' to fix this UAF problem. | ["https://git.kernel.org/stable/c/22327bd7988f21de3a53c1373f3b81542bfe1f44","https://git.kernel.org/stable/c/30bf7244acf32f19cb722c39f7bc1c2a9f300422","https://git.kernel.org/stable/c/3bd2454162ec6bbb5503233c804fce6e4b6dcec5","https://git.kernel.org/stable/c/4c7c44ee1650677fbe89d86edbad9497b7679b5c","https://git.kernel.org/stable/c/7a75740206af5f17e9f3efa384211cba70213da1","https://git.kernel.org/stable/c/7bb7428dd73991bf4b3a7a61b493ca50046c2b13","https://git.kernel.org/stable/c/8c0f024f29e055840a5a89fe23b96ae3f921afed","https://git.kernel.org/stable/c/9150cb625b46f68d524f4cfd491f1aafc23e10a9","https://git.kernel.org/stable/c/c3b07c875fa8f906f932976460fd14798596f101"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49111 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix use after free in hci_send_acl This fixes the following trace caused by receiving HCI_EV_DISCONN_PHY_LINK_COMPLETE which does call hci_conn_del without first checking if conn->type is in fact AMP_LINK and in case it is do properly cleanup upper layers with hci_disconn_cfm: ================================================================== BUG: KASAN: use-after-free in hci_send_acl+0xaba/0xc50 Read of size 8 at addr ffff88800e404818 by task bluetoothd/142 CPU: 0 PID: 142 Comm: bluetoothd Not tainted 5.17.0-rc5-00006-gda4022eeac1a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x45/0x59 print_address_description.constprop.0+0x1f/0x150 kasan_report.cold+0x7f/0x11b hci_send_acl+0xaba/0xc50 l2cap_do_send+0x23f/0x3d0 l2cap_chan_send+0xc06/0x2cc0 l2cap_sock_sendmsg+0x201/0x2b0 sock_sendmsg+0xdc/0x110 sock_write_iter+0x20f/0x370 do_iter_readv_writev+0x343/0x690 do_iter_write+0x132/0x640 vfs_writev+0x198/0x570 do_writev+0x202/0x280 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RSP: 002b:00007ffce8a099b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10 RDX: 0000000000000001 RSI: 00007ffce8a099e0 RDI: 0000000000000015 RAX: ffffffffffffffda RBX: 00007ffce8a099e0 RCX: 00007f788fc3cf77 R10: 00007ffce8af7080 R11: 0000000000000246 R12: 000055e4ccf75580 RBP: 0000000000000015 R08: 0000000000000002 R09: 0000000000000001 </TASK> R13: 000055e4ccf754a0 R14: 000055e4ccf75cd0 R15: 000055e4ccf4a6b0 Allocated by task 45: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 hci_chan_create+0x9a/0x2f0 l2cap_conn_add.part.0+0x1a/0xdc0 l2cap_connect_cfm+0x236/0x1000 le_conn_complete_evt+0x15a7/0x1db0 hci_le_conn_complete_evt+0x226/0x2c0 hci_le_meta_evt+0x247/0x450 hci_event_packet+0x61b/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 Freed by task 45: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfb/0x130 kfree+0xac/0x350 hci_conn_cleanup+0x101/0x6a0 hci_conn_del+0x27e/0x6c0 hci_disconn_phylink_complete_evt+0xe0/0x120 hci_event_packet+0x812/0xe90 hci_rx_work+0x4d5/0xc50 process_one_work+0x8fb/0x15a0 worker_thread+0x576/0x1240 kthread+0x29d/0x340 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff88800c0f0500 The buggy address is located 24 bytes inside of which belongs to the cache kmalloc-128 of size 128 The buggy address belongs to the page: 128-byte region [ffff88800c0f0500, ffff88800c0f0580) flags: 0x100000000000200(slab|node=0|zone=1) page:00000000fe45cd86 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xc0f0 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 raw: 0100000000000200 ffffea00003a2c80 dead000000000004 ffff8880078418c0 page dumped because: kasan: bad access detected ffff88800c0f0400: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc Memory state around the buggy address: >ffff88800c0f0500: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800c0f0480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800c0f0580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ---truncated--- | ["https://git.kernel.org/stable/c/2cc803804ec9a296b3156855d6c8c4ca1c6b84be","https://git.kernel.org/stable/c/3803d896ddd97c7c16689a5381c0960040727647","https://git.kernel.org/stable/c/4da302b90b96c309987eb9b37c8547f939f042d2","https://git.kernel.org/stable/c/643a6c26bd32e339d00ad97b8822b6db009e803c","https://git.kernel.org/stable/c/684e505406abaeabe0058e9776f9210bf2747953","https://git.kernel.org/stable/c/b3c2ea1fd444b3bb7b82bfd2c3a45418f85c2502","https://git.kernel.org/stable/c/c41de54b0a963e59e4dd04c029a4a6d73f45ef9c","https://git.kernel.org/stable/c/d404765dffdbd8dcd14758695d0c96c52fb2e624","https://git.kernel.org/stable/c/f63d24baff787e13b723d86fe036f84bdbc35045"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49275 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: m_can: m_can_tx_handler(): fix use after free of skb can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. | ["https://git.kernel.org/stable/c/08d90846e438ac22dc56fc49ec0b0d195831c5ed","https://git.kernel.org/stable/c/2e8e79c416aae1de224c0f1860f2e3350fa171f8","https://git.kernel.org/stable/c/31417073493f302d26ab66b3abc098d43227b835","https://git.kernel.org/stable/c/4db7d6f481990dd179a9ee7126dc7aa31ea4fff3","https://git.kernel.org/stable/c/7728d937ec403a1ceff9483023252d2cb8777f81","https://git.kernel.org/stable/c/869016a2938ac44f7b2fb7fc22c89edad99eb9b3","https://git.kernel.org/stable/c/d3892a747ab16b1eb6593a19d29f62c3b3f020ac","https://git.kernel.org/stable/c/d93ed9aff64968f4cdad690712eb4f48ae537bde","https://git.kernel.org/stable/c/f43e64076ff1b1dcb893fb77ad1204105f710a29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49416 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix use-after-free in chanctx code In ieee80211_vif_use_reserved_context(), when we have an old context and the new context's replace_state is set to IEEE80211_CHANCTX_REPLACE_NONE, we free the old context in ieee80211_vif_use_reserved_reassign(). Therefore, we cannot check the old_ctx anymore, so we should set it to NULL after this point. However, since the new_ctx replace state is clearly not IEEE80211_CHANCTX_REPLACES_OTHER, we're not going to do anything else in this function and can just return to avoid accessing the freed old_ctx. | ["https://git.kernel.org/stable/c/265bec4779a38b65e86a25120370f200822dfa76","https://git.kernel.org/stable/c/2965c4cdf7ad9ce0796fac5e57debb9519ea721e","https://git.kernel.org/stable/c/4ba81e794f0fad6234f644c2da1ae14d5b95e1c4","https://git.kernel.org/stable/c/4f05a9e15edcdf5b97e0d86ab6ecd5f187289f6c","https://git.kernel.org/stable/c/6118bbdf69f4718b02d26bbcf2e497eb66004331","https://git.kernel.org/stable/c/82c8e7bbdd06c7ed58e22450cc5b37f33a25bb2c","https://git.kernel.org/stable/c/88cc8f963febe192d6ded9df7217f92f380b449a","https://git.kernel.org/stable/c/9f1e5cc85ad77e52f54049a94db0407445ae2a34","https://git.kernel.org/stable/c/b79110f2bf6022e60e590d2e094728a8eec3e79e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49474 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix dangling sco_conn and use-after-free in sco_sock_timeout Connecting the same socket twice consecutively in sco_sock_connect() could lead to a race condition where two sco_conn objects are created but only one is associated with the socket. If the socket is closed before the SCO connection is established, the timer associated with the dangling sco_conn object won't be canceled. As the sock object is being freed, the use-after-free problem happens when the timer callback function sco_sock_timeout() accesses the socket. Here's the call trace: dump_stack+0x107/0x163 ? refcount_inc+0x1c/ print_address_description.constprop.0+0x1c/0x47e ? refcount_inc+0x1c/0x7b kasan_report+0x13a/0x173 ? refcount_inc+0x1c/0x7b check_memory_region+0x132/0x139 refcount_inc+0x1c/0x7b sco_sock_timeout+0xb2/0x1ba process_one_work+0x739/0xbd1 ? cancel_delayed_work+0x13f/0x13f ? __raw_spin_lock_init+0xf0/0xf0 ? to_kthread+0x59/0x85 worker_thread+0x593/0x70e kthread+0x346/0x35a ? drain_workqueue+0x31a/0x31a ? kthread_bind+0x4b/0x4b ret_from_fork+0x1f/0x30 | ["https://git.kernel.org/stable/c/36c644c63bfcaee2d3a426f45e89a9cd09799318","https://git.kernel.org/stable/c/390d82733a953c1fabf3de9c9618091a7a9c90a6","https://git.kernel.org/stable/c/537f619dea4e3fa8ed1f8f938abffe3615794bcc","https://git.kernel.org/stable/c/65d347cb39e2e6bd0c2a745ad7c928998ebb0162","https://git.kernel.org/stable/c/6f55fac0af3531cf60d11369454c41f5fc81ab3f","https://git.kernel.org/stable/c/7aa1e7d15f8a5b65f67bacb100d8fc033b21efa2","https://git.kernel.org/stable/c/7d61dbd7311ab978d8ddac1749a758de4de00374","https://git.kernel.org/stable/c/99df16007f4bbf9abfc3478cb17d10f0d7f8906e","https://git.kernel.org/stable/c/9de3dc09e56f8deacd2bdbf4cecb71e11a312405"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49478 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix array-index-out-of-bounds in pvr2_i2c_core_init Syzbot reported that -1 is used as array index. The problem was in missing validation check. hdw->unit_number is initialized with -1 and then if init table walk fails this value remains unchanged. Since code blindly uses this member for array indexing adding sanity check is the easiest fix for that. hdw->workpoll initialization moved upper to prevent warning in __flush_work. | ["https://git.kernel.org/stable/c/1310fc3538dcc375a2f46ef0a438512c2ca32827","https://git.kernel.org/stable/c/24e807541e4a9263ed928e6ae3498de3ad43bd1e","https://git.kernel.org/stable/c/2e004fe914b243db41fa96f9e583385f360ea58e","https://git.kernel.org/stable/c/3309c2c574e13b21b44729f5bdbf21f60189b79a","https://git.kernel.org/stable/c/4351bfe36aba9fa7dc9d68d498d25d41a0f45e67","https://git.kernel.org/stable/c/471bec68457aaf981add77b4f590d65dd7da1059","https://git.kernel.org/stable/c/a3304766d9384886e6d3092c776273526947a2e9","https://git.kernel.org/stable/c/a3660e06675bccec4bf149c7229ea1d491ba10d7","https://git.kernel.org/stable/c/f99a8b1ec0eddc2931aeaa4f490277a15b39f511"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49493 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync. | ["https://git.kernel.org/stable/c/061a6159cea583f1155f67d1915917a6b9282662","https://git.kernel.org/stable/c/0941150100173d4eaf3fe08ff4b16740e7c3026f","https://git.kernel.org/stable/c/1a5a3dfd9f172dcb115072f0aea5e27d3083c20e","https://git.kernel.org/stable/c/236d29c5857f02e0a53fdf15d3dce1536c4322ce","https://git.kernel.org/stable/c/2def44d3aec59e38d2701c568d65540783f90f2f","https://git.kernel.org/stable/c/453f0920ffc1a28e28ddb9c3cd5562472b2895b0","https://git.kernel.org/stable/c/7d801e807536a9a9c2146c5f4a5836f154517ed3","https://git.kernel.org/stable/c/88c09e4812d72c3153afc8e5a45ecac2d0eae3ff","https://git.kernel.org/stable/c/abe7554da62cb489712a54de69ef5665c250e564"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49505 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFC: NULL out the dev->rfkill to prevent UAF Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device") assumes the device_is_registered() in function nfc_dev_up() will help to check when the rfkill is unregistered. However, this check only take effect when device_del(&dev->dev) is done in nfc_unregister_device(). Hence, the rfkill object is still possible be dereferenced. The crash trace in latest kernel (5.18-rc2): [ 68.760105] ================================================================== [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750 [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313 [ 68.760756] [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4 [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 68.760756] Call Trace: [ 68.760756] <TASK> [ 68.760756] dump_stack_lvl+0x57/0x7d [ 68.760756] print_report.cold+0x5e/0x5db [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] kasan_report+0xbe/0x1c0 [ 68.760756] ? __lock_acquire+0x3ec1/0x6750 [ 68.760756] __lock_acquire+0x3ec1/0x6750 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? register_lock_class+0x18d0/0x18d0 [ 68.760756] lock_acquire+0x1ac/0x4f0 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0 [ 68.760756] ? nla_get_range_signed+0x540/0x540 [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50 [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50 [ 68.760756] ? rfkill_blocked+0xe/0x60 [ 68.760756] rfkill_blocked+0xe/0x60 [ 68.760756] nfc_dev_up+0x84/0x260 [ 68.760756] nfc_genl_dev_up+0x90/0xe0 [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0 [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230 [ 68.760756] ? security_capable+0x51/0x90 [ 68.760756] genl_rcv_msg+0x280/0x500 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? lock_acquire+0x1ac/0x4f0 [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0 [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 68.760756] netlink_rcv_skb+0x11b/0x340 [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0 [ 68.760756] ? netlink_ack+0x9c0/0x9c0 [ 68.760756] ? netlink_deliver_tap+0x136/0xb00 [ 68.760756] genl_rcv+0x1f/0x30 [ 68.760756] netlink_unicast+0x430/0x710 [ 68.760756] ? memset+0x20/0x40 [ 68.760756] ? netlink_attachskb+0x740/0x740 [ 68.760756] ? __build_skb_around+0x1f4/0x2a0 [ 68.760756] netlink_sendmsg+0x75d/0xc00 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] ? netlink_unicast+0x710/0x710 [ 68.760756] sock_sendmsg+0xdf/0x110 [ 68.760756] __sys_sendto+0x19e/0x270 [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0 [ 68.760756] ? fd_install+0x178/0x4c0 [ 68.760756] ? fd_install+0x195/0x4c0 [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0 [ 68.760756] __x64_sys_sendto+0xd8/0x1b0 [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130 [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50 [ 68.760756] do_syscall_64+0x3b/0x90 [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 68.760756] RIP: 0033:0x7f67fb50e6b3 ... [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3 [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003 [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003 [ 68.760756] </TASK> [ 68.760756] [ 68.760756] Allocated by task 279: [ 68.760756] kasan_save_stack+0x1e/0x40 [ ---truncated--- | ["https://git.kernel.org/stable/c/1632be63862f183cd5cf1cc094e698e6ec005dfd","https://git.kernel.org/stable/c/1b0e81416a24d6e9b8c2341e22e8bf48f8b8bfc9","https://git.kernel.org/stable/c/2a1b5110c95e4d49c8c3906270dfcde680a5a7be","https://git.kernel.org/stable/c/4a68938f43b7c2663e4c90bb9bbe29ac8b9a42a0","https://git.kernel.org/stable/c/4f5d71930f41be78557f9714393179025baacd65","https://git.kernel.org/stable/c/6abfaca8711803d0d7cc8c0fac1070a88509d463","https://git.kernel.org/stable/c/a8e03bcad52dc9afabf650fdbad84f739cec9efa","https://git.kernel.org/stable/c/f81270125b50532624400063281e6611ecd61ddf","https://git.kernel.org/stable/c/fbf9c4c714d3cdeb98b6a18e4d057f931cad1d81"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49530 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: fix double free in si_parse_power_table() In function si_parse_power_table(), array adev->pm.dpm.ps and its member is allocated. If the allocation of each member fails, the array itself is freed and returned with an error code. However, the array is later freed again in si_dpm_fini() function which is called when the function returns an error. This leads to potential double free of the array adev->pm.dpm.ps, as well as leak of its array members, since the members are not freed in the allocation function and the array is not nulled when freed. In addition adev->pm.dpm.num_ps, which keeps track of the allocated array member, is not updated until the member allocation is successfully finished, this could also lead to either use after free, or uninitialized variable access in si_dpm_fini(). Fix this by postponing the free of the array until si_dpm_fini() and increment adev->pm.dpm.num_ps everytime the array member is allocated. | ["https://git.kernel.org/stable/c/2615464854505188f909d0c07c37a6623693b5c7","https://git.kernel.org/stable/c/43eb9b667b95f2a31c63e8949b0d2161b9be59c3","https://git.kernel.org/stable/c/6c5bdaa1325be7f04b79ea992ab216739192d342","https://git.kernel.org/stable/c/a5ce7051db044290b1a95045ff03c249005a3aa4","https://git.kernel.org/stable/c/af832028af6f44c6c45645757079c4ed6884ade5","https://git.kernel.org/stable/c/c0e811c4ccf3b42705976285e3a94cc82dea7300","https://git.kernel.org/stable/c/ca1ce206894dd976275c78ee38dbc19873f22de9","https://git.kernel.org/stable/c/f3fa2becf2fc25b6ac7cf8d8b1a2e4a86b3b72bd","https://git.kernel.org/stable/c/fd2eff8b9dcbe469c3b7bbbc7083ab5ed94de07b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52885 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix UAF in svc_tcp_listen_data_ready() After the listener svc_sock is freed, and before invoking svc_tcp_accept() for the established child sock, there is a window that the newsock retaining a freed listener svc_sock in sk_user_data which cloning from parent. In the race window, if data is received on the newsock, we will observe use-after-free report in svc_tcp_listen_data_ready(). Reproduce by two tasks: 1. while :; do rpc.nfsd 0 ; rpc.nfsd; done 2. while :; do echo "" | ncat -4 127.0.0.1 2049 ; done KASAN report: ================================================================== BUG: KASAN: slab-use-after-free in svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] Read of size 8 at addr ffff888139d96228 by task nc/102553 CPU: 7 PID: 102553 Comm: nc Not tainted 6.3.0+ #18 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <IRQ> dump_stack_lvl+0x33/0x50 print_address_description.constprop.0+0x27/0x310 print_report+0x3e/0x70 kasan_report+0xae/0xe0 svc_tcp_listen_data_ready+0x1cf/0x1f0 [sunrpc] tcp_data_queue+0x9f4/0x20e0 tcp_rcv_established+0x666/0x1f60 tcp_v4_do_rcv+0x51c/0x850 tcp_v4_rcv+0x23fc/0x2e80 ip_protocol_deliver_rcu+0x62/0x300 ip_local_deliver_finish+0x267/0x350 ip_local_deliver+0x18b/0x2d0 ip_rcv+0x2fb/0x370 __netif_receive_skb_one_core+0x166/0x1b0 process_backlog+0x24c/0x5e0 __napi_poll+0xa2/0x500 net_rx_action+0x854/0xc90 __do_softirq+0x1bb/0x5de do_softirq+0xcb/0x100 </IRQ> <TASK> ... </TASK> Allocated by task 102371: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_kmalloc+0x7b/0x90 svc_setup_socket+0x52/0x4f0 [sunrpc] svc_addsock+0x20d/0x400 [sunrpc] __write_ports_addfd+0x209/0x390 [nfsd] write_ports+0x239/0x2c0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 102551: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x50 __kasan_slab_free+0x106/0x190 __kmem_cache_free+0x133/0x270 svc_xprt_free+0x1e2/0x350 [sunrpc] svc_xprt_destroy_all+0x25a/0x440 [sunrpc] nfsd_put+0x125/0x240 [nfsd] nfsd_svc+0x2cb/0x3c0 [nfsd] write_threads+0x1ac/0x2a0 [nfsd] nfsctl_transaction_write+0xac/0x110 [nfsd] vfs_write+0x1c3/0xae0 ksys_write+0xed/0x1c0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Fix the UAF by simply doing nothing in svc_tcp_listen_data_ready() if state != TCP_LISTEN, that will avoid dereferencing svsk for all child socket. | ["https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b","https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f","https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428","https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065","https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254","https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e","https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee","https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287","https://git.kernel.org/stable/c/42725e5c1b181b757ba11d804443922982334d9b","https://git.kernel.org/stable/c/7e1f989055622fd086c5dfb291fc72adf5660b6f","https://git.kernel.org/stable/c/c7b8c2d06e437639694abe76978e915cfb73f428","https://git.kernel.org/stable/c/cd5ec3ee52ce4b7e283cc11facfa420c297c8065","https://git.kernel.org/stable/c/dfc896c4a75cb8cd7cb2dfd9b469cf1e3f004254","https://git.kernel.org/stable/c/ef047411887ff0845afd642d6a687819308e1a4e","https://git.kernel.org/stable/c/fbf4ace39b2e4f3833236afbb2336edbafd75eee","https://git.kernel.org/stable/c/fc80fc2d4e39137869da3150ee169b40bf879287"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52664 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: eliminate double free in error handling logic Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer. | ["https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d","https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928","https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf","https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d","https://git.kernel.org/stable/c/0edb3ae8bfa31cd544b0c195bdec00e036002b5d","https://git.kernel.org/stable/c/b3cb7a830a24527877b0bc900b9bd74a96aea928","https://git.kernel.org/stable/c/c11a870a73a3bc4cc7df6dd877a45b181795fcbf","https://git.kernel.org/stable/c/d1fde4a7e1dcc4d49cce285107a7a43c3030878d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52921 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix possible UAF in amdgpu_cs_pass1() Since the gang_size check is outside of chunk parsing loop, we need to reset i before we free the chunk data. Suggested by Ye Zhang (@VAR10CK) of Baidu Security. | ["https://git.kernel.org/stable/c/90e065677e0362a777b9db97ea21d43a39211399","https://git.kernel.org/stable/c/9a2393af1f35d1975204fc00035c64a1c792b278","https://git.kernel.org/stable/c/e08e9dd09809b16f8f8cee8c466841b33d24ed96"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53126 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). | ["https://git.kernel.org/stable/c/0b364cf53b20204e92bac7c6ebd1ee7d3ec62931","https://git.kernel.org/stable/c/5bb287da2d2d5bb8f7376e223b02edb16998982e","https://git.kernel.org/stable/c/d372dd09cfbf1324f54cbffd81fcaf6cdf3e608e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26928 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: client: fix potential UAF in cifs_debug_files_proc_show() Skip sessions that are being teared down (status == SES_EXITING) to avoid UAF. | ["https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88","https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1","https://git.kernel.org/stable/c/8f8718afd446cd4ea3b62bacc3eec09f8aae85ee","https://git.kernel.org/stable/c/a140224bcf87eb98a87b67ff4c6826c57e47b704","https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d","https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502","https://git.kernel.org/stable/c/229042314602db62559ecacba127067c22ee7b88","https://git.kernel.org/stable/c/3402faf78b2516b0af1259baff50cc8453ef0bd1","https://git.kernel.org/stable/c/a65f2b56334ba4dc30bd5ee9ce5b2691b973344d","https://git.kernel.org/stable/c/ca545b7f0823f19db0f1148d59bc5e1a56634502"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2977 | High | fixed |
|
A flaw was found in the Linux kernel implementation of proxied virtualized TPM devices. On a system where virtualized TPM devices are configured (this is not the default) a local attacker can create a use-after-free and create a situation where it may be possible to escalate privileges on the system. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f","https://security.netapp.com/advisory/ntap-20230214-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d8e7007dc7c4d7c8366739bbcd3f5e51dcd470f","https://security.netapp.com/advisory/ntap-20230214-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49622 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: avoid skb access on nf_stolen When verdict is NF_STOLEN, the skb might have been freed. When tracing is enabled, this can result in a use-after-free: 1. access to skb->nf_trace 2. access to skb->mark 3. computation of trace id 4. dump of packet payload To avoid 1, keep a cached copy of skb->nf_trace in the trace state struct. Refresh this copy whenever verdict is != STOLEN. Avoid 2 by skipping skb->mark access if verdict is STOLEN. 3 is avoided by precomputing the trace id. Only dump the packet when verdict is not "STOLEN". | ["https://git.kernel.org/stable/c/0016d5d46d7440729a3132f61a8da3bf7f84e2ba","https://git.kernel.org/stable/c/e34b9ed96ce3b06c79bf884009b16961ca478f87"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49651 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: srcu: Tighten cleanup_srcu_struct() GP checks Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct(). | ["https://git.kernel.org/stable/c/8ed00760203d8018bee042fbfe8e076579be2c2b","https://git.kernel.org/stable/c/e997dda6502eefbc1032d6b0da7b353c53344b07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0562 | High | fixed |
|
A use-after-free flaw was found in the Linux Kernel. When a disk is removed, bdi_unregister is called to stop further write-back and waits for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation work after this has completed, which can result in the timer attempting to access the recently freed bdi_writeback. | ["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/security/cve/CVE-2024-0562","https://bugzilla.redhat.com/show_bug.cgi?id=2258475","https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/security/cve/CVE-2024-0562","https://bugzilla.redhat.com/show_bug.cgi?id=2258475","https://patchwork.kernel.org/project/linux-mm/patch/20220801155034.3772543-1-khazhy@google.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21751 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: HWS, change error flow on matcher disconnect Currently, when firmware failure occurs during matcher disconnect flow, the error flow of the function reconnects the matcher back and returns an error, which continues running the calling function and eventually frees the matcher that is being disconnected. This leads to a case where we have a freed matcher on the matchers list, which in turn leads to use-after-free and eventual crash. This patch fixes that by not trying to reconnect the matcher back when some FW command fails during disconnect. Note that we're dealing here with FW error. We can't overcome this problem. This might lead to bad steering state (e.g. wrong connection between matchers), and will also lead to resource leakage, as it is the case with any other error handling during resource destruction. However, the goal here is to allow the driver to continue and not crash the machine with use-after-free error. | ["https://git.kernel.org/stable/c/1ce840c7a659aa53a31ef49f0271b4fd0dc10296","https://git.kernel.org/stable/c/23a86c76a1a197e8fbbbd0ce3e826eb58c471624"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21693 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: zswap: properly synchronize freeing resources during CPU hotunplug In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU. If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e. acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp). The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made. Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed. Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acomp_ctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU. The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression. Previously a fix was attempted by holding cpus_read_lock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2]. Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in handling the race between the refcount dropping to zero in zswap_[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues. [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/ [yosryahmed@google.com: remove comment] | ["https://git.kernel.org/stable/c/12dcb0ef540629a281533f9dedc1b6b8e14cfb65","https://git.kernel.org/stable/c/8d29ff5d50304daa41dc3cfdda4a9d1e46cf5be1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-51780 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. do_vcc_ioctl in net/atm/ioctl.c has a use-after-free because of a vcc_recvmsg race condition. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://security.netapp.com/advisory/ntap-20240419-0001/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/24e90b9e34f9e039f56b5f25f6e6eb92cdd8f4b3","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://security.netapp.com/advisory/ntap-20240419-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6270 | High | fixed |
|
A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. | ["https://access.redhat.com/security/cve/CVE-2023-6270","https://bugzilla.redhat.com/show_bug.cgi?id=2256786","https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/block/aoe?h=v6.9\u0026id=f98364e926626c678fb4b9004b75cacf92ff0662","https://access.redhat.com/security/cve/CVE-2023-6270","https://bugzilla.redhat.com/show_bug.cgi?id=2256786","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1055 | High | fixed |
|
A use-after-free exists in the Linux Kernel in tc_new_tfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5 | ["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://security.netapp.com/advisory/ntap-20220506-0007/","https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://kernel.dance/#04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5","https://security.netapp.com/advisory/ntap-20220506-0007/","https://syzkaller.appspot.com/bug?id=2212474c958978ab86525fe6832ac8102c309ffc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46791 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open The mcp251x_hw_wake() function is called with the mpc_lock mutex held and disables the interrupt handler so that no interrupts can be processed while waking the device. If an interrupt has already occurred then waiting for the interrupt handler to complete will deadlock because it will be trying to acquire the same mutex. CPU0 CPU1 ---- ---- mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() <interrupt> mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlock Use disable_irq_nosync() instead because the interrupt handler does everything while holding the mutex so it doesn't matter if it's still running. | ["https://git.kernel.org/stable/c/3a49b6b1caf5cefc05264d29079d52c99cb188e0","https://git.kernel.org/stable/c/513c8fc189b52f7922e36bdca58997482b198f0e","https://git.kernel.org/stable/c/7dd9c26bd6cf679bcfdef01a8659791aa6487a29","https://git.kernel.org/stable/c/8fecde9c3f9a4b97b68bb97c9f47e5b662586ba7","https://git.kernel.org/stable/c/e554113a1cd2a9cfc6c7af7bdea2141c5757e188","https://git.kernel.org/stable/c/f7ab9e14b23a3eac6714bdc4dba244d8aa1ef646"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57882 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix TCP options overflow. Syzbot reported the following splat: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:_compound_head include/linux/page-flags.h:242 [inline] RIP: 0010:put_page+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_page_unref include/linux/skbuff_ref.h:43 [inline] __skb_frag_unref include/linux/skbuff_ref.h:56 [inline] skb_release_data+0x483/0x8a0 net/core/skbuff.c:1119 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb+0x55/0x70 net/core/skbuff.c:1204 tcp_clean_rtx_queue net/ipv4/tcp_input.c:3436 [inline] tcp_ack+0x2442/0x6bc0 net/ipv4/tcp_input.c:4032 tcp_rcv_state_process+0x8eb/0x44e0 net/ipv4/tcp_input.c:6805 tcp_v4_do_rcv+0x77d/0xc70 net/ipv4/tcp_ipv4.c:1939 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5672 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5785 process_backlog+0x662/0x15b0 net/core/dev.c:6117 __napi_poll+0xcb/0x490 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:7074 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK> Eric noted a probable shinfo->nr_frags corruption, which indeed occurs. The root cause is a buggy MPTCP option len computation in some circumstances: the ADD_ADDR option should be mutually exclusive with DSS since the blamed commit. Still, mptcp_established_options_add_addr() tries to set the relevant info in mptcp_out_options, if ---truncated--- | ["https://git.kernel.org/stable/c/09ba95321a269019b5aa8e0c3bc80cf86d91fd18","https://git.kernel.org/stable/c/53fe947f67c93a5334aed3a7259fcc8a204f8bb6","https://git.kernel.org/stable/c/88b01048f286bb522f524ad99943ba86797d6514","https://git.kernel.org/stable/c/cbb26f7d8451fe56ccac802c6db48d16240feebd","https://git.kernel.org/stable/c/fb08e6b0ba284e3dcdc9378de26dcb51d90710f5","http://www.openwall.com/lists/oss-security/2025/04/01/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57938 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sctp: Prevent autoclose integer overflow in sctp_association_init() While by default max_autoclose equals to INT_MAX / HZ, one may set net.sctp.max_autoclose to UINT_MAX. There is code in sctp_association_init() that can consequently trigger overflow. | ["https://git.kernel.org/stable/c/081bdb3a31674339313c6d702af922bc29de2c53","https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94","https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477","https://git.kernel.org/stable/c/4e86729d1ff329815a6e8a920cb554a1d4cb5b8d","https://git.kernel.org/stable/c/7af63ef5fe4d480064eb22583b24ffc8b408183a","https://git.kernel.org/stable/c/94b7ed0a4896420988e1776942f0a3f67167873e","https://git.kernel.org/stable/c/f9c3adb083d3278f065a83c3f667f1246c74c31f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52918 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: pci: cx23885: check cx23885_vdev_init() return cx23885_vdev_init() can return a NULL pointer, but that pointer is used in the next line without a check. Add a NULL pointer check and go to the error unwind if it is NULL. | ["https://git.kernel.org/stable/c/06ee04a907d64ee3910fecedd05d7f1be4b1b70e","https://git.kernel.org/stable/c/15126b916e39b0cb67026b0af3c014bfeb1f76b3","https://git.kernel.org/stable/c/199a42fc4c45e8b7f19efeb15dbc36889a599ac2","https://git.kernel.org/stable/c/8e31b096e2e1949bc8f0be019c9ae70d414404c6","https://git.kernel.org/stable/c/a5f1d30c51c485cec7a7de60205667c3ff86c303","https://git.kernel.org/stable/c/b1397fb4a779fca560c43d2acf6702d41b4a495b","https://git.kernel.org/stable/c/e7385510e2550a9f8b6f3d5f33c5b894ab9ba976"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47667 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Add workaround for Errata #i2037 (AM65x SR 1.0) Errata #i2037 in AM65x/DRA80xM Processors Silicon Revision 1.0 (SPRZ452D_July 2018_Revised December 2019 [1]) mentions when an inbound PCIe TLP spans more than two internal AXI 128-byte bursts, the bus may corrupt the packet payload and the corrupt data may cause associated applications or the processor to hang. The workaround for Errata #i2037 is to limit the maximum read request size and maximum payload size to 128 bytes. Add workaround for Errata #i2037 here. The errata and workaround is applicable only to AM65x SR 1.0 and later versions of the silicon will have this fixed. [1] -> https://www.ti.com/lit/er/sprz452i/sprz452i.pdf | ["https://git.kernel.org/stable/c/135843c351c08df72bdd4b4ebea53c8052a76881","https://git.kernel.org/stable/c/576d0fb6f8d4bd4695e70eee173a1b9c7bae9572","https://git.kernel.org/stable/c/86f271f22bbb6391410a07e08d6ca3757fda01fa","https://git.kernel.org/stable/c/af218c803fe298ddf00abef331aa526b20d7ea61","https://git.kernel.org/stable/c/cfb006e185f64edbbdf7869eac352442bc76b8f6","https://git.kernel.org/stable/c/dd47051c76c8acd8cb983f01b4d1265da29cb66a","https://git.kernel.org/stable/c/ebbdbbc580c1695dec283d0ba6448729dc993246"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47674 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: avoid leaving partial pfn mappings around in error case As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. | ["https://git.kernel.org/stable/c/3213fdcab961026203dd587a4533600c70b3336b","https://git.kernel.org/stable/c/35770ca6180caa24a2b258c99a87bd437a1ee10f","https://git.kernel.org/stable/c/5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959","https://git.kernel.org/stable/c/65d0db500d7c07f0f76fc24a4d837791c4862cd2","https://git.kernel.org/stable/c/79a61cc3fc0466ad2b7b89618a6157785f0293b3","https://git.kernel.org/stable/c/954fd4c81f22c4b6ba65379a81fd252971bf4ef3","https://git.kernel.org/stable/c/a95a24fcaee1b892e47d5e6dcc403f713874ee80","https://project-zero.issues.chromium.org/issues/366053091"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49868 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: <TASK> commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that. | ["https://git.kernel.org/stable/c/1282f001cbf56e5dd6e90a18e205a566793f4be0","https://git.kernel.org/stable/c/37fee9c220b92c3b7bf22b51c51dde5364e7590b","https://git.kernel.org/stable/c/39356ec0e319ed07627b3a0f402d0608546509e6","https://git.kernel.org/stable/c/7ad0c5868f2f0418619089513d95230c66cb7eb4","https://git.kernel.org/stable/c/c3b47f49e83197e8dffd023ec568403bcdbb774b","https://git.kernel.org/stable/c/d13249c0df7aab885acb149695f82c54c0822a70","https://git.kernel.org/stable/c/d73d48acf36f57362df7e4f9d76568168bf5e944","https://git.kernel.org/stable/c/dc02c1440705e3451abd1c2c8114a5c1bb188e9f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49890 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity. | ["https://git.kernel.org/stable/c/016bf0294b401246471c6710c6bf9251616228b6","https://git.kernel.org/stable/c/186fb12e7a7b038c2710ceb2fb74068f1b5d55a4","https://git.kernel.org/stable/c/29f388945770bd0a6c82711436b2bc98b0dfac92","https://git.kernel.org/stable/c/8adf4408d482faa51b2c14e60bfd9946ec1911a4","https://git.kernel.org/stable/c/9550d8d6f19fac7623f044ae8d9503825b325497","https://git.kernel.org/stable/c/b511474f49588cdca355ebfce54e7eddbf7b75a5","https://git.kernel.org/stable/c/fd5f4ac1a986f0e7e9fa019201b5890554f87bcf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49892 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity. | ["https://git.kernel.org/stable/c/1f9f8186e239222f1c8d3dd73bf3bc6ae86c5e76","https://git.kernel.org/stable/c/3334ab72cbba55a632f24579cd47c4a4e5e69cda","https://git.kernel.org/stable/c/4067f4fa0423a89fb19a30b57231b384d77d2610","https://git.kernel.org/stable/c/8f0abb39c16e719129de10596b3ae3363fa178b4","https://git.kernel.org/stable/c/a23d6029e730f8a151b1a34afb169baac1274583","https://git.kernel.org/stable/c/bc00d211da4ffad5314a2043b50bdc8ff8a33724","https://git.kernel.org/stable/c/c7630935d9a4986e8c0ed91658a781b7a77d73f7","https://git.kernel.org/stable/c/f921335123f6620c3dce5c96fbb95f18524a021c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49907 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing "dc" to "dc->hwss.apply_idle_power_optimizations", which dereferences null "dc->clk_mgr". (The function pointer resolves to "dcn35_apply_idle_power_optimizations".) This fixes 1 FORWARD_NULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/3f7e533c10db3d0158709a99e2129ff63add6bcd","https://git.kernel.org/stable/c/5ba3fbf75b243b2863a8be9e7c393e003d3b88f3","https://git.kernel.org/stable/c/8d54001f8dccd56146973f23f3ab2ba037a21251","https://git.kernel.org/stable/c/95d9e0803e51d5a24276b7643b244c7477daf463","https://git.kernel.org/stable/c/9641bc4adf8446034e490ed543ae7e9833cfbdf5","https://git.kernel.org/stable/c/a2773e0a4b79e7a6463abdffaf8cc4f24428ba18","https://git.kernel.org/stable/c/a545a9403e04c6e17fdc04a26a61d9feebbba106"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49913 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906) | ["https://git.kernel.org/stable/c/1ebfa6663807c144be8c8b6727375012409d2356","https://git.kernel.org/stable/c/3929e382e4758aff42da0102a60d13337c99d3b8","https://git.kernel.org/stable/c/40193ff73630adf76bc0d82398f7d90fb576dba4","https://git.kernel.org/stable/c/66d71a72539e173a9b00ca0b1852cbaa5f5bf1ad","https://git.kernel.org/stable/c/73efd2a611b62fee71a7b7f27d9d08bb60da8a72","https://git.kernel.org/stable/c/8ab59527852a6f7780aad6185729550ca0569122","https://git.kernel.org/stable/c/e47e563c6f0db7d792a559301862c19ead0dfc2f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49927 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. | ["https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71","https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0","https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f","https://git.kernel.org/stable/c/e479cb835feeb2abff97f25766e23b96a6eabe28","https://git.kernel.org/stable/c/ec862cd843faa6f0e84a7a07362f2786446bf697","https://git.kernel.org/stable/c/f17efbeb2922327ea01a9efa8829fea9a30e547d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49933 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: <IRQ> dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits. | ["https://git.kernel.org/stable/c/1ab2cfe19700fb3dde4c7dfec392acff34db3120","https://git.kernel.org/stable/c/1b120f151871eb47ce9f283c007af3f8ae1d990e","https://git.kernel.org/stable/c/1f61d509257d6a05763d05bf37943b35306522b1","https://git.kernel.org/stable/c/364022095bdd4108efdaaa68576afa4712a5d085","https://git.kernel.org/stable/c/59121bb38fdc01434ea3fe361ee02b59f036227f","https://git.kernel.org/stable/c/9bce8005ec0dcb23a58300e8522fe4a31da606fa","https://git.kernel.org/stable/c/f4ef9bef023d5c543cb0f3194ecacfd47ef590ec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49935 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 <power_saving_thread+776>: mov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b <power_saving_thread+779>: mov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 <power_saving_thread+787>: lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 <pad_busy_cpus_bits> crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ] | ["https://git.kernel.org/stable/c/03593dbb0b272ef7b0358b099841e65735422aca","https://git.kernel.org/stable/c/0a2ed70a549e61c5181bad5db418d223b68ae932","https://git.kernel.org/stable/c/27c045f868f0e5052c6b532868a65e0cd250c8fc","https://git.kernel.org/stable/c/68a599da16ebad442ce295d8d2d5c488e3992822","https://git.kernel.org/stable/c/68a8e45743d6a120f863fb14b72dc59616597019","https://git.kernel.org/stable/c/92e5661b7d0727ab912b76625a88b33fdb9b609a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50003 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85) | ["https://git.kernel.org/stable/c/52d4e3fb3d340447dcdac0e14ff21a764f326907","https://git.kernel.org/stable/c/68d603f467a75618eeae5bfe8af32cda47097010","https://git.kernel.org/stable/c/722d2d8fc423108597b97efbf165187d16d9aa1e","https://git.kernel.org/stable/c/73e441be033d3ed0bdff09b575da3e7d4606ffc9","https://git.kernel.org/stable/c/c2356296f546326f9f06c109e201d42201e1e783","https://git.kernel.org/stable/c/eb9329cd882aa274e92bdb1003bc088433fdee86"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50049 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/65b2d49e55fe13ae56da3a7685bdccadca31134a","https://git.kernel.org/stable/c/97a79933fb08a002ba9400d1a7a5df707ecdb896","https://git.kernel.org/stable/c/a9b4fd1946678fa0e069e442f3c5a7d3fa446fac","https://git.kernel.org/stable/c/c643ef59390e49f1dfab35e8ea65f5db5e527d64","https://git.kernel.org/stable/c/f4149eec960110ffd5bcb161075dd9f1d7773075","https://git.kernel.org/stable/c/ff599ef6970ee000fa5bc38d02fa5ff5f3fc7575"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50058 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected "uart_port_dtr_rts(uport, false);" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks. | ["https://git.kernel.org/stable/c/2fe399bb8efd0d325ab1138cf8e3ecf23a39e96d","https://git.kernel.org/stable/c/399927f0f875b93f3d5a0336d382ba48b8671eb2","https://git.kernel.org/stable/c/602babaa84d627923713acaf5f7e9a4369e77473","https://git.kernel.org/stable/c/76ed24a34223bb2c6b6162e1d8389ec4e602a290","https://git.kernel.org/stable/c/d7b5876a6e74cdf8468a478be6b23f2f5464ac7a","https://git.kernel.org/stable/c/e418d91195d29d5f9c9685ff309b92b04b41dc40"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50095 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 </IRQ> <TASK> asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 </TASK> Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs | ["https://git.kernel.org/stable/c/2a777679b8ccd09a9a65ea0716ef10365179caac","https://git.kernel.org/stable/c/3e799fa463508abe7a738ce5d0f62a8dfd05262a","https://git.kernel.org/stable/c/7022a517bf1ca37ef5a474365bcc5eafd345a13a","https://git.kernel.org/stable/c/713adaf0ecfc49405f6e5d9e409d984f628de818","https://git.kernel.org/stable/c/a195a42dd25ca4f12489687065d00be64939409f","https://git.kernel.org/stable/c/e80eadb3604a92d2d086e956b8b2692b699d4d0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50134 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. | ["https://git.kernel.org/stable/c/02c86c5d5ef4bbba17d38859c74872825f536617","https://git.kernel.org/stable/c/34a422274b693507025a7db21519865d1862afcb","https://git.kernel.org/stable/c/7458a6cdaebb3dc59af8578ee354fae78a154c4a","https://git.kernel.org/stable/c/75f828e944dacaac8870418461d3d48a1ecf2331","https://git.kernel.org/stable/c/9eb32bd23bbcec44bcbef27b7f282b7a7f3d0391","https://git.kernel.org/stable/c/d92b90f9a54d9300a6e883258e79f36dab53bfae","https://git.kernel.org/stable/c/fae9dc12c61ce23cf29d09824a741b7b1ff8f01f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47736 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference. | ["https://git.kernel.org/stable/c/1bf7e414cac303c9aec1be67872e19be8b64980c","https://git.kernel.org/stable/c/9cfa199bcbbbba31cbf97b2786f44f4464f3f29a","https://git.kernel.org/stable/c/9e2f9d34dd12e6e5b244ec488bcebd0c2d566c50","https://git.kernel.org/stable/c/b9b30af0e86ffb485301ecd83b9129c9dfb7ebf8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56369 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/modes: Avoid divide by zero harder in drm_mode_vrefresh() drm_mode_vrefresh() is trying to avoid divide by zero by checking whether htotal or vtotal are zero. But we may still end up with a div-by-zero of vtotal*htotal*... | ["https://git.kernel.org/stable/c/47c8b6cf1d08f0ad40d7ea7b025442e51b35ee1f","https://git.kernel.org/stable/c/69fbb01e891701e6d04db1ddb5ad49e42c4dd963","https://git.kernel.org/stable/c/9398332f23fab10c5ec57c168b44e72997d6318e","https://git.kernel.org/stable/c/b39de5a71bac5641d0fda33d1cf5682d82cf1ae5","https://git.kernel.org/stable/c/e7c7b48a0fc5ed83baae400a1b15e33978c25d7f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49891 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler. | ["https://git.kernel.org/stable/c/232a138bd843d48cb2368f604646d990db7640f3","https://git.kernel.org/stable/c/2be1d4f11944cd6283cb97268b3e17c4424945ca","https://git.kernel.org/stable/c/5873aa7f814754085d418848b2089ef406a02dd0","https://git.kernel.org/stable/c/99a801e2fca39a6f31e543fc3383058a8955896f","https://git.kernel.org/stable/c/fd665c8dbdb19548965b0ae80c490de00e906366"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49897 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity. | ["https://git.kernel.org/stable/c/1decf695ce08e23d9ded6ce83d121b2282ce9899","https://git.kernel.org/stable/c/3718a619a8c0a53152e76bb6769b6c414e1e83f4","https://git.kernel.org/stable/c/3ba1219e299ab5462b5cb374c2fa2a67af0ea190","https://git.kernel.org/stable/c/d247af7c5dbf143ad6be8179bb1550e76d6af57e","https://git.kernel.org/stable/c/db1d7e1794fed62ee16d6a72a85997bb069e2e27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49898 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. | ["https://git.kernel.org/stable/c/115b1a3b0944b4d8ef0b4b0c5a625bdd9474131f","https://git.kernel.org/stable/c/26d262b79a3587aaa84368586a55e9026c67841b","https://git.kernel.org/stable/c/367cd9ceba1933b63bc1d87d967baf6d9fd241d2","https://git.kernel.org/stable/c/3fc70ae048fe0936761b73b50700a810ff61e853","https://git.kernel.org/stable/c/c3a3b6d9a9383e3c1a4a08878ba5046e68647595"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49909 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma. | ["https://git.kernel.org/stable/c/28574b08c70e56d34d6f6379326a860b96749051","https://git.kernel.org/stable/c/496486950c3d2aebf46a3be300296ac091da7a2d","https://git.kernel.org/stable/c/5298270bdabe97be5b8236e544c9e936415fe1f2","https://git.kernel.org/stable/c/e087c9738ee1cdeebde346f4dfc819e5f7057e90","https://git.kernel.org/stable/c/f38b09ba6a335c511eb27920bb9bb4a1b2c20084"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49911 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048. | ["https://git.kernel.org/stable/c/02411e9359297512946705b1cd8cf5e6b0806fa0","https://git.kernel.org/stable/c/62ed6f0f198da04e884062264df308277628004f","https://git.kernel.org/stable/c/827380b114f83c30b3e56d1a675980b6d65f7c88","https://git.kernel.org/stable/c/8c854138b593efbbd8fa46a25f3288c121c1d1a1","https://git.kernel.org/stable/c/e8a24767899c86f4c5f1e4d3b2608942d054900f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782) | ["https://git.kernel.org/stable/c/0d94d9cbd9fec7344d230c4f7b781826f7799c60","https://git.kernel.org/stable/c/7d1854c86d02cea8f8a0c0ca05f4ab14292baf3d","https://git.kernel.org/stable/c/c395fd47d1565bd67671f45cca281b3acc2c31ef","https://git.kernel.org/stable/c/ec1be3c527b4a5fc85bcc1b0be7cec08bf60c796","https://git.kernel.org/stable/c/f0454b3cb0584a6bf275aeb49be61a760fd546a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49917 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628) | ["https://git.kernel.org/stable/c/205e3b96cc9aa9211fd2c849a16245cf236b2d36","https://git.kernel.org/stable/c/23cb6139543580dc36743586ca86fbb3f7ab2c9d","https://git.kernel.org/stable/c/5443c83eb8fd2f88c71ced38848fbf744d6206a2","https://git.kernel.org/stable/c/56c326577971adc3a230f29dfd3aa3abdd505f5d","https://git.kernel.org/stable/c/cba7fec864172dadd953daefdd26e01742b71a6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49925 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed. | ["https://git.kernel.org/stable/c/2a9c40c72097b583b23aeb2a26d429ccfc81fbc1","https://git.kernel.org/stable/c/36bfefb6baaa8e46de44f4fd919ce4347337620f","https://git.kernel.org/stable/c/4684d69b9670a83992189f6271dc0fcdec4ed0d7","https://git.kernel.org/stable/c/872cd2d029d2c970a8a1eea88b48dab2b3f2e93a","https://git.kernel.org/stable/c/95cdd538e0e5677efbdf8aade04ec098ab98f457"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49929 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either. | ["https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284","https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28","https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e","https://git.kernel.org/stable/c/cbc6fc9cfcde151ff5eadaefdc6155f99579384f","https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49939 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: <TASK> ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 </TASK> Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/37c319503023de49a4c87301c8998c8d928112cb","https://git.kernel.org/stable/c/490eddc836b2a6ec286e5df14bed4c7cf5e1f475","https://git.kernel.org/stable/c/7dd5d2514a8ea58f12096e888b0bd050d7eae20a","https://git.kernel.org/stable/c/b04650b5a9990cf5c0de480e62c68199f1396a04","https://git.kernel.org/stable/c/fdc73f2cfbe897f4733156df211d79ced649b23c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58071 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: team: prevent adding a device which is already a team device lower Prevent adding a device which is already a team device lower, e.g. adding veth0 if vlan1 was already added and veth0 is a lower of vlan1. This is not useful in practice and can lead to recursive locking: $ ip link add veth0 type veth peer name veth1 $ ip link set veth0 up $ ip link set veth1 up $ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1 $ ip link add team0 type team $ ip link set veth0.1 down $ ip link set veth0.1 master team0 team0: Port device veth0.1 added $ ip link set veth0 down $ ip link set veth0 master team0 ============================================ WARNING: possible recursive locking detected 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted -------------------------------------------- ip/7684 is trying to acquire lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) but task is already holding lock: ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977) other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(team->team_lock_key); lock(team->team_lock_key); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by ip/7684: stack backtrace: CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_deadlock_bug.cold (kernel/locking/lockdep.c:3040) __lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226) ? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548) lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2)) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? lock_acquire (kernel/locking/lockdep.c:5822) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) __mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) ? fib_sync_up (net/ipv4/fib_semantics.c:2167) ? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) __dev_notify_flags (net/core/dev.c:8993) ? __dev_change_flags (net/core/dev.c:8975) dev_change_flags (net/core/dev.c:9027) vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470) ? br_device_event (net/bridge/br.c:143) notifier_call_chain (kernel/notifier.c:85) call_netdevice_notifiers_info (net/core/dev.c:1996) dev_open (net/core/dev.c:1519 net/core/dev.c:1505) team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977) ? __pfx_team_add_slave (drivers/net/team/team_core.c:1972) do_set_master (net/core/rtnetlink.c:2917) do_setlink.isra.0 (net/core/rtnetlink.c:3117) | ["https://git.kernel.org/stable/c/0a7794b9ca78c8e7d001c583bf05736169de3f20","https://git.kernel.org/stable/c/184a564e6000b41582f160a5be9a9b5aabe22ac1","https://git.kernel.org/stable/c/1bb06f919fa5bec77ad9b6002525c3dcc5c1fd6c","https://git.kernel.org/stable/c/3fff5da4ca2164bb4d0f1e6cd33f6eb8a0e73e50","https://git.kernel.org/stable/c/62ff1615815d565448c37cb8a7a2a076492ec471","https://git.kernel.org/stable/c/adff6ac889e16d97abd1e4543f533221127e978a","https://git.kernel.org/stable/c/bd099a2fa9be983ba0e90a57a59484fe9d520ba8","https://git.kernel.org/stable/c/d9bce1310c0e2a55888e3e08c9f69d8377b3a377"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21749 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: rose: lock the socket in rose_bind() syzbot reported a soft lockup in rose_loopback_timer(), with a repro calling bind() from multiple threads. rose_bind() must lock the socket to avoid this issue. | ["https://git.kernel.org/stable/c/4c04b0ab3a647e76d0e752b013de8e404abafc63","https://git.kernel.org/stable/c/667f61b3498df751c8b3f0be1637e7226cbe3ed0","https://git.kernel.org/stable/c/970cd2ed26cdab2b0f15b6d90d7eaa36538244a5","https://git.kernel.org/stable/c/a1300691aed9ee852b0a9192e29e2bdc2411a7e6","https://git.kernel.org/stable/c/b8bf5c3fb778bbb1f3ff7d98ec577c969f687513","https://git.kernel.org/stable/c/d308661a0f4e7c8e86dfc7074a55ee5894c61538","https://git.kernel.org/stable/c/e0384efd45f615603e6869205b72040c209e69cc","https://git.kernel.org/stable/c/ed00c5f907d08a647b8bf987514ad8c6b17971a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21859 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: gadget: f_midi: f_midi_complete to call queue_work When using USB MIDI, a lock is attempted to be acquired twice through a re-entrant call to f_midi_transmit, causing a deadlock. Fix it by using queue_work() to schedule the inner f_midi_transmit() via a high priority work queue from the completion handler. | ["https://git.kernel.org/stable/c/1f10923404705a94891e612dff3b75e828a78368","https://git.kernel.org/stable/c/24a942610ee9bafb2692a456ae850c5b2e409b05","https://git.kernel.org/stable/c/4ab37fcb42832cdd3e9d5e50653285ca84d6686f","https://git.kernel.org/stable/c/727dee0857946b85232526de4f5a957fe163e89a","https://git.kernel.org/stable/c/8aa6b4be1f4efccbfc533e6ec8841d26e4fa8dba","https://git.kernel.org/stable/c/b09957657d7767d164b3432af2129bd72947553c","https://git.kernel.org/stable/c/deeee3adb2c01eedab32c3b4519337689ad02e8a","https://git.kernel.org/stable/c/e9fec6f42c45db2f62dc373fb1a10d2488c04e79"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47809 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dlm: fix possible lkb_resource null dereference This patch fixes a possible null pointer dereference when this function is called from request_lock() as lkb->lkb_resource is not assigned yet, only after validate_lock_args() by calling attach_lkb(). Another issue is that a resource name could be a non printable bytearray and we cannot assume to be ASCII coded. The log functionality is probably never being hit when DLM is used in normal way and no debug logging is enabled. The null pointer dereference can only occur on a new created lkb that does not have the resource assigned yet, it probably never hits the null pointer dereference but we should be sure that other changes might not change this behaviour and we actually can hit the mentioned null pointer dereference. In this patch we just drop the printout of the resource name, the lkb id is enough to make a possible connection to a resource name if this exists. | ["https://git.kernel.org/stable/c/2db11504ef82a60c1a2063ba7431a5cd013ecfcb","https://git.kernel.org/stable/c/6fbdc3980b70e9c1c86eccea7d5ee68108008fa7","https://git.kernel.org/stable/c/b98333c67daf887c724cd692e88e2db9418c0861"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21658 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: avoid NULL pointer dereference if no valid extent tree [BUG] Syzbot reported a crash with the following call trace: BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Call Trace: <TASK> scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] scrub_simple_mirror+0x175/0x260 [btrfs] scrub_stripe+0x5d4/0x6c0 [btrfs] scrub_chunk+0xbb/0x170 [btrfs] scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> [CAUSE] The reproducer is using a corrupted image where extent tree root is corrupted, thus forcing to use "rescue=all,ro" mount option to mount the image. Then it triggered a scrub, but since scrub relies on extent tree to find where the data/metadata extents are, scrub_find_fill_first_stripe() relies on an non-empty extent root. But unfortunately scrub_find_fill_first_stripe() doesn't really expect an NULL pointer for extent root, it use extent_root to grab fs_info and triggered a NULL pointer dereference. [FIX] Add an extra check for a valid extent root at the beginning of scrub_find_fill_first_stripe(). The new error path is introduced by 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots"), but that's pretty old, and later commit b979547513ff ("btrfs: scrub: introduce helper to find and fill sector info for a scrub_stripe") changed how we do scrub. So for kernels older than 6.6, the fix will need manual backport. | ["https://git.kernel.org/stable/c/24b85a8b0310e0144da9ab30be42e87e6476638a","https://git.kernel.org/stable/c/6aecd91a5c5b68939cf4169e32bc49f3cd2dd329","https://git.kernel.org/stable/c/aee5f69f3e6cd82bfefaca1b70b40b6cd8f3f784"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44956 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences. | ["https://git.kernel.org/stable/c/3cd1585e57908b6efcd967465ef7685f40b2a294","https://git.kernel.org/stable/c/458bb83119dfee5d14c677f7846dd9363817006f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48952 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: mt7621: Add sentinel to quirks table Current driver is missing a sentinel in the struct soc_device_attribute array, which causes an oops when assessed by the soc_device_match(mt7621_pcie_quirks_match) call. This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attr was fixed to register the SOC as a device, in: commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early") Fix it by adding the required sentinel. | ["https://git.kernel.org/stable/c/19098934f910b4d47cb30251dd39ffa57bef9523","https://git.kernel.org/stable/c/3e9c395ef2d52975b2c2894d2da09d6db2958bc6","https://git.kernel.org/stable/c/a4997bae1b5b012c8a6e2643e26578a7bc2cae36","https://git.kernel.org/stable/c/cb7323ece786f243f6d6ccf2e5b2b27b736bdc04"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48959 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: sja1105: fix memory leak in sja1105_setup_devlink_regions() When dsa_devlink_region_create failed in sja1105_setup_devlink_regions(), priv->regions is not released. | ["https://git.kernel.org/stable/c/4be43e46c3f945fc7dd9e23c73a7a66927a3b814","https://git.kernel.org/stable/c/78a9ea43fc1a7c06a420b132d2d47cbf4344a5df","https://git.kernel.org/stable/c/e5e59629654b8826f0167dae480d0e3fa0f8f038","https://git.kernel.org/stable/c/f3b5dda26cd0535aac09ed09c5d83f19b979ec9f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48995 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send() There is a kmemleak when test the raydium_i2c_ts with bpf mock device: unreferenced object 0xffff88812d3675a0 (size 8): comm "python3", pid 349, jiffies 4294741067 (age 95.695s) hex dump (first 8 bytes): 11 0e 10 c0 01 00 04 00 ........ backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000006e631aee>] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 unreferenced object 0xffff88812d3675c8 (size 8): comm "python3", pid 349, jiffies 4294741070 (age 95.692s) hex dump (first 8 bytes): 22 00 36 2d 81 88 ff ff ".6-.... backtrace: [<0000000068427125>] __kmalloc+0x46/0x1b0 [<0000000090180f91>] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts] [<000000001d5c9620>] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts] [<00000000dc6fcf38>] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts] [<00000000a310de16>] i2c_device_probe+0x651/0x680 [<00000000f5a96bf3>] really_probe+0x17c/0x3f0 [<00000000096ba499>] __driver_probe_device+0xe3/0x170 [<00000000c5acb4d9>] driver_probe_device+0x49/0x120 [<00000000264fe082>] __device_attach_driver+0xf7/0x150 [<00000000f919423c>] bus_for_each_drv+0x114/0x180 [<00000000e067feca>] __device_attach+0x1e5/0x2d0 [<0000000054301fc2>] bus_probe_device+0x126/0x140 [<00000000aad93b22>] device_add+0x810/0x1130 [<00000000c086a53f>] i2c_new_client_device+0x352/0x4e0 [<000000003c2c248c>] of_i2c_register_device+0xf1/0x110 [<00000000ffec4177>] of_i2c_notify+0x100/0x160 After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed. | ["https://git.kernel.org/stable/c/097c1c7a28e3da8f2811ba532be6e81faab15aab","https://git.kernel.org/stable/c/53b9b1201e34ccc895971218559123625c56fbcd","https://git.kernel.org/stable/c/8c9a59939deb4bfafdc451100c03d1e848b4169b","https://git.kernel.org/stable/c/a82869ac52f3d9db4b2cf8fd41edc2dee7a75a61"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50098 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c | ["https://git.kernel.org/stable/c/19a198b67767d952c8f3d0cf24eb3100522a8223","https://git.kernel.org/stable/c/7774d23622416dbbbdb21bf342b3f0d92cf1dc0f","https://git.kernel.org/stable/c/7bd9af254275fad7071d85f04616560deb598d7d","https://git.kernel.org/stable/c/7de759fceacff5660abf9590d11114215a9d5f3c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47735 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2] | ["https://git.kernel.org/stable/c/07f0f643d7e570dbe8ef6f5c3367a43e3086a335","https://git.kernel.org/stable/c/094a1821903f33fb91de4b71087773ee16aeb3a0","https://git.kernel.org/stable/c/2656336a84fcb6802f6e6c233f4661891deea24f","https://git.kernel.org/stable/c/29c0f546d3fd66238b42cf25bcd5f193bb1cf794","https://git.kernel.org/stable/c/425589d4af09c49574bd71ac31f811362a5126c3","https://git.kernel.org/stable/c/74d315b5af180220d561684d15897730135733a6","https://git.kernel.org/stable/c/a1a3403bb1826c8ec787f0d60c3e7b54f419129e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49985 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. | ["https://git.kernel.org/stable/c/048bbbdbf85e5e00258dfb12f5e368f908801d7b","https://git.kernel.org/stable/c/1883cad2cc629ded4a3556c0bbb8b42533ad8764","https://git.kernel.org/stable/c/22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba","https://git.kernel.org/stable/c/894cd5f5fd9061983445bbd1fa3d81be43095344","https://git.kernel.org/stable/c/9b8bc33ad64192f54142396470cc34ce539a8940","https://git.kernel.org/stable/c/c2024b1a583ab9176c797ea1e5f57baf8d5e2682","https://git.kernel.org/stable/c/d6f1250a4d5773f447740b9fe37b8692105796d4","https://git.kernel.org/stable/c/fac3c9f7784e8184c0338e9f0877b81e55d3ef1c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49858 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic. | ["https://git.kernel.org/stable/c/11690d7e76842f29b60fbb5b35bc97d206ea0e83","https://git.kernel.org/stable/c/19fd2f2c5fb36b61506d3208474bfd8fdf1cada3","https://git.kernel.org/stable/c/2e6871a632a99d9b9e2ce3a7847acabe99e5a26e","https://git.kernel.org/stable/c/38d9b07d99b789efb6d8dda21f1aaad636c38993","https://git.kernel.org/stable/c/5b22c038fb2757c652642933de5664da471f8cb7","https://git.kernel.org/stable/c/77d48d39e99170b528e4f2e9fc5d1d64cdedd386","https://git.kernel.org/stable/c/f76b69ab9cf04358266e3cea5748c0c2791fbb08"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42239 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fail bpf_timer_cancel when callback is being cancelled Given a schedule: timer1 cb timer2 cb bpf_timer_cancel(timer2); bpf_timer_cancel(timer1); Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup. Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another. Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors. Background on prior attempts: Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status. lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false; The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status. It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again. Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel. | ["https://git.kernel.org/stable/c/3e4e8178a8666c56813bd167b848fca0f4c9af0a","https://git.kernel.org/stable/c/9369830518688ecd5b08ffc08ab3302ce2b5d0f7","https://git.kernel.org/stable/c/d4523831f07a267a943f0dde844bf8ead7495f13"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50166 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fsl/fman: Fix refcount handling of fman-related devices In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev->dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks. Add references release. | ["https://git.kernel.org/stable/c/1dec67e0d9fbb087c2ab17bf1bd17208231c3bb1","https://git.kernel.org/stable/c/3c2a3619d565fe16bf59b0a047bab103a2ee4490","https://git.kernel.org/stable/c/5ed4334fc9512f934fe2ae9c4cf7f8142e451b8b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46783 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: fix return value of tcp_bpf_sendmsg() When we cork messages in psock->cork, the last message triggers the flushing will result in sending a sk_msg larger than the current message size. In this case, in tcp_bpf_send_verdict(), 'copied' becomes negative at least in the following case: 468 case __SK_DROP: 469 default: 470 sk_msg_free_partial(sk, msg, tosend); 471 sk_msg_apply_bytes(psock, tosend); 472 *copied -= (tosend + delta); // <==== HERE 473 return -EACCES; Therefore, it could lead to the following BUG with a proper value of 'copied' (thanks to syzbot). We should not use negative 'copied' as a return value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/126d72b726c4cf1119f3a7fe413a78d341c3fea9","https://git.kernel.org/stable/c/3efe53eb221a38e207c1e3f81c51e4ca057d50c2","https://git.kernel.org/stable/c/6f9fdf5806cced888c43512bccbdf7fefd50f510","https://git.kernel.org/stable/c/78bb38d9c5a311c5f8bdef7c9557d7d81ca30e4a","https://git.kernel.org/stable/c/810a4e7d92dea4074cb04c25758320909d752193","https://git.kernel.org/stable/c/c8219a27fa43a2cbf99f5176f6dddfe73e7a24ae","https://git.kernel.org/stable/c/fe1910f9337bd46a9343967b547ccab26b4b2c6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46817 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Stop amdgpu_dm initialize when stream nums greater than 6 [Why] Coverity reports OVERRUN warning. Should abort amdgpu_dm initialize. [How] Return failure to amdgpu_dm_init. | ["https://git.kernel.org/stable/c/21bbb39863f10f5fb4bf772d15b07d5d13590e9d","https://git.kernel.org/stable/c/28b515c458aa9c92bfcb99884c94713a5f471cea","https://git.kernel.org/stable/c/754321ed63f0a4a31252ca72e0bd89a9e1888018","https://git.kernel.org/stable/c/84723eb6068c50610c5c0893980d230d7afa2105","https://git.kernel.org/stable/c/94cb77700fa4ae6200486bfa0ba2ac547534afd2","https://git.kernel.org/stable/c/d398c74c881dee695f6eb6138c9891644e1c3d9d","https://git.kernel.org/stable/c/d619b91d3c4af60ac422f1763ce53d721fb91262"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50177 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] <TASK> [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation. | ["https://git.kernel.org/stable/c/27bc3da5eae57e3af8f5648b4498ffde48781434","https://git.kernel.org/stable/c/eaf3adb8faab611ba57594fa915893fc93a7788c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46803 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check debug trap enable before write dbg_ev_file In interrupt context, write dbg_ev_file will be run by work queue. It will cause write dbg_ev_file execution after debug_trap_disable, which will cause NULL pointer access. v2: cancel work "debug_event_workarea" before set dbg_ev_file as NULL. | ["https://git.kernel.org/stable/c/547033b593063eb85bfdf9b25a5f1b8fd1911be2","https://git.kernel.org/stable/c/820dcbd38a77bd5fdc4236d521c1c122841227d0","https://git.kernel.org/stable/c/e6ea3b8fe398915338147fe54dd2db8155fdafd8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2020-10742 | Medium | N/A | A flaw was found in the Linux kernel. An index buffer overflow during Direct IO write leading to the NFS client to crash. In some cases, a reach out of the index after one memory allocation by kmalloc will cause a kernel panic. The highest threat from this vulnerability is to data confidentiality and system availability. | ["https://bugzilla.redhat.com/show_bug.cgi?id=1835127","https://bugzilla.redhat.com/show_bug.cgi?id=1835127"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2327 | High | N/A | io_uring use work_flags to determine which identity need to grab from the calling process to make sure it is consistent with the calling process when executing IORING_OP. Some operations are missing some types, which can lead to incorrect reference counts which can then lead to a double free. We recommend upgrading the kernel past commit df3f3bb5059d20ef094d6b2f0256c4bf4127a859 | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://kernel.dance/#df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://security.netapp.com/advisory/ntap-20230203-0009/","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://kernel.dance/#df3f3bb5059d20ef094d6b2f0256c4bf4127a859","https://security.netapp.com/advisory/ntap-20230203-0009/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52746 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() int type = nla_type(nla); if (type > XFRMA_MAX) { return -EOPNOTSUPP; } @type is then used as an array index and can be used as a Spectre v1 gadget. if (nla_len(nla) < compat_policy[type].len) { array_index_nospec() can be used to prevent leaking content of kernel memory to malicious users. | ["https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d","https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5","https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0","https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff","https://git.kernel.org/stable/c/419674224390fca298020fc0751a20812f84b12d","https://git.kernel.org/stable/c/5dc688fae6b7be9dbbf5304a3d2520d038e06db5","https://git.kernel.org/stable/c/a893cc644812728e86e9aff517fd5698812ecef0","https://git.kernel.org/stable/c/b6ee896385380aa621102e8ea402ba12db1cabff"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42156 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe copies of clear-key structures on failure Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key. | ["https://git.kernel.org/stable/c/7f6243edd901b75aaece326c90a1cc0dcb60cc3d","https://git.kernel.org/stable/c/a891938947f4427f98cb1ce54f27223501efe750","https://git.kernel.org/stable/c/d65d76a44ffe74c73298ada25b0f578680576073","https://git.kernel.org/stable/c/7f6243edd901b75aaece326c90a1cc0dcb60cc3d","https://git.kernel.org/stable/c/d65d76a44ffe74c73298ada25b0f578680576073"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1943 | High | fixed |
|
A flaw out of bounds memory write in the Linux kernel UDF file system functionality was found in the way user triggers some file operation which triggers udf_write_fi(). A local user could use this flaw to crash the system or potentially | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1ad35dd0548ce947d97aaf92f7f2f9a202951cf","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c1ad35dd0548ce947d97aaf92f7f2f9a202951cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-28893 | High | fixed |
|
The SUNRPC subsystem in the Linux kernel through 5.17.2 can call xs_xprt_free before ensuring that sockets are in the intended state. | ["http://www.openwall.com/lists/oss-security/2022/04/11/3","http://www.openwall.com/lists/oss-security/2022/04/11/4","http://www.openwall.com/lists/oss-security/2022/04/11/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a","https://security.netapp.com/advisory/ntap-20220526-0002/","https://www.debian.org/security/2022/dsa-5161","http://www.openwall.com/lists/oss-security/2022/04/11/3","http://www.openwall.com/lists/oss-security/2022/04/11/4","http://www.openwall.com/lists/oss-security/2022/04/11/5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1a3b1bba7c7a5eb8a11513cf88427cb9d77bc60a","https://security.netapp.com/advisory/ntap-20220526-0002/","https://www.debian.org/security/2022/dsa-5161"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-30594 | High | fixed |
|
The Linux kernel before 5.17.2 mishandles seccomp permissions. The PTRACE_SEIZE code path allows attackers to bypass intended restrictions on setting the PT_SUSPEND_SECCOMP flag. | ["http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2276","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3","https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0001/","https://www.debian.org/security/2022/dsa-5173","http://packetstormsecurity.com/files/167386/Kernel-Live-Patch-Security-Notice-LSN-0086-1.html","http://packetstormsecurity.com/files/170362/Linux-PT_SUSPEND_SECCOMP-Permission-Bypass-Ptracer-Death-Race.html","https://bugs.chromium.org/p/project-zero/issues/detail?id=2276","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ee1fee900537b5d9560e9f937402de5ddc8412f3","https://github.com/torvalds/linux/commit/ee1fee900537b5d9560e9f937402de5ddc8412f3","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0001/","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48958 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ethernet: aeroflex: fix potential skb leak in greth_init_rings() The greth_init_rings() function won't free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it. Compile tested only. | ["https://git.kernel.org/stable/c/063a932b64db3317ec020c94466fe52923a15f60","https://git.kernel.org/stable/c/223654e2e2c8d05347cd8e300f8d1ec6023103dd","https://git.kernel.org/stable/c/87277bdf2c370ab2d07cfe77dfa9b37f82bbe1e5","https://git.kernel.org/stable/c/99669d94ce145389f1d6f197e6e18ed50d43fb76","https://git.kernel.org/stable/c/bfaa8f6c5b84b295dd73b0138b57c5555ca12b1c","https://git.kernel.org/stable/c/c7adcbd0fd3fde1b19150c3e955fb4a30c5bd9b7","https://git.kernel.org/stable/c/cb1e293f858e5e1152b8791047ed4bdaaf392189","https://git.kernel.org/stable/c/dd62867a6383f78f75f07039394aac25924a3307"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48971 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix not cleanup led when bt_init fails bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it. This can cause panic if the argument "bluetooth-power" in text is freed and then another led_trigger_register() tries to access it: BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30 Call Trace: <TASK> led_trigger_register+0x10d/0x4f0 led_trigger_register_simple+0x7d/0x100 bt_init+0x39/0xf7 [bluetooth] do_one_initcall+0xd0/0x4e0 | ["https://git.kernel.org/stable/c/2c6cf0afc3856359e620e96edd952457d258e16c","https://git.kernel.org/stable/c/2f3957c7eb4e07df944169a3e50a4d6790e1c744","https://git.kernel.org/stable/c/5ecf7cd6fde5e72c87122084cf00d63e35d8dd9f","https://git.kernel.org/stable/c/8a66c3a94285552f6a8e45d73b34ebbad11d388b","https://git.kernel.org/stable/c/e7b950458156d410509a08c41930b75e72985938","https://git.kernel.org/stable/c/edf7284a98296369dd0891a0457eec37df244873"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48973 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: amd8111: Fix PCI device reference count leak for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL. If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() after the 'out' label. Since pci_dev_put() can handle NULL input parameter, there is no problem for the 'Device not found' branch. For the normal path, add pci_dev_put() in amd_gpio_exit(). | ["https://git.kernel.org/stable/c/4271515f189bd5fe2ec86b4089dab7cb804625d2","https://git.kernel.org/stable/c/45fecdb9f658d9c82960c98240bc0770ade19aca","https://git.kernel.org/stable/c/4749c5cc147c9860b96db1e71cc36d1de1bd3f59","https://git.kernel.org/stable/c/48bd5d3801f6b67cc144449d434abbd5043a6d37","https://git.kernel.org/stable/c/5ee6413d3dd972930af787b2c0c7aaeb379fa521","https://git.kernel.org/stable/c/71d591ef873f9ebb86cd8d053b3caee785b2de6a","https://git.kernel.org/stable/c/b2bc053ebbba57a06fa655db5ea796de2edce445","https://git.kernel.org/stable/c/e364ce04d8f840478b09eee57b614de7cf1e743e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49005 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Fix bounds check for _sx controls For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value. | ["https://git.kernel.org/stable/c/325d94d16e3131b54bdf07356e4cd855e0d853fc","https://git.kernel.org/stable/c/46bab25cc0230df60d1c02b651cc5640a14b08df","https://git.kernel.org/stable/c/4a95a49f26308782b4056401989ecd7768fda8fa","https://git.kernel.org/stable/c/698813ba8c580efb356ace8dbf55f61dac6063a8","https://git.kernel.org/stable/c/73dce3c1d48c4662bdf3ccbde1492c2cb4bfd8ce","https://git.kernel.org/stable/c/98b15c706644bebc19d2e77ccc360cc51444f6d0","https://git.kernel.org/stable/c/b50c9641897274c3faef5f95ac852f54b94be2e8","https://git.kernel.org/stable/c/e46adadf19248d59af3aa6bc52e09115bf479bf7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) Check for null before removing sysfs attrs If coretemp_add_core() gets an error then pdata->core_data[indx] is already NULL and has been kfreed. Don't pass that to sysfs_remove_group() as that will crash in sysfs_remove_group(). [Shortened for readability] [91854.020159] sysfs: cannot create duplicate filename '/devices/platform/coretemp.0/hwmon/hwmon2/temp20_label' <cpu offline> [91855.126115] BUG: kernel NULL pointer dereference, address: 0000000000000188 [91855.165103] #PF: supervisor read access in kernel mode [91855.194506] #PF: error_code(0x0000) - not-present page [91855.224445] PGD 0 P4D 0 [91855.238508] Oops: 0000 [#1] PREEMPT SMP PTI ... [91855.342716] RIP: 0010:sysfs_remove_group+0xc/0x80 ... [91855.796571] Call Trace: [91855.810524] coretemp_cpu_offline+0x12b/0x1dd [coretemp] [91855.841738] ? coretemp_cpu_online+0x180/0x180 [coretemp] [91855.871107] cpuhp_invoke_callback+0x105/0x4b0 [91855.893432] cpuhp_thread_fun+0x8e/0x150 ... Fix this by checking for NULL first. | ["https://git.kernel.org/stable/c/070d5ea4a0592a37ad96ce7f7b6b024f90bb009f","https://git.kernel.org/stable/c/280110db1a7d62ad635b103bafc3ae96e8bef75c","https://git.kernel.org/stable/c/7692700ac818866d138a8de555130a6e70e6ac16","https://git.kernel.org/stable/c/89eecabe6a47403237f45aafd7d24f93cb973653","https://git.kernel.org/stable/c/a89ff5f5cc64b9fe7a992cf56988fd36f56ca82a","https://git.kernel.org/stable/c/ae6c8b6e5d5628df1c475c0a8fca1465e205c95b","https://git.kernel.org/stable/c/f06e0cd01eab954bd5f2190c9faa79bb5357e05b","https://git.kernel.org/stable/c/fb503d077ff7b43913503eaf72995d1239028b99"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49011 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new() As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak. | ["https://git.kernel.org/stable/c/0dd1da5a15eeecb2fe4cf131b3216fb455af783c","https://git.kernel.org/stable/c/2f74cffc7c85f770b1b1833dccb03b8cde3be102","https://git.kernel.org/stable/c/6e035d5a2a6b907cfce9a80c5f442c2e459cd34e","https://git.kernel.org/stable/c/7dec14537c5906b8bf40fd6fd6d9c3850f8df11d","https://git.kernel.org/stable/c/bb75a0d1223d43f97089841aecb28a9b4de687a9","https://git.kernel.org/stable/c/c40db1e5f316792b557d2be37e447c20d9ac4635","https://git.kernel.org/stable/c/ea5844f946b1ec5c0b7c115cd7684f34fd48021b","https://git.kernel.org/stable/c/f598da27acbeee414679cacd14294db3e273e3d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49020 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/9p: Fix a potential socket leak in p9_socket_open Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak. This patch adds sock_release() to fix the leak issue. | ["https://git.kernel.org/stable/c/0396227f4daf4792a6a8aaa3b7771dc25c4cd443","https://git.kernel.org/stable/c/2d24d91b9f44620824fc37b766f7cae00ca32748","https://git.kernel.org/stable/c/8782b32ef867de7981bbe9e86ecb90e92e8780bd","https://git.kernel.org/stable/c/8b14bd0b500aec1458b51cb621c8e5fab3304260","https://git.kernel.org/stable/c/aa08323fe18cb7cf95317ffa2d54ca1de8e74ebd","https://git.kernel.org/stable/c/dcc14cfd7debe11b825cb077e75d91d2575b4cb8","https://git.kernel.org/stable/c/ded893965b895b2dccd3d1436d8d3daffa23ea64","https://git.kernel.org/stable/c/e01c1542379fb395e7da53706df598f38905dfbf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48868 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Let probe fail when workqueue cannot be enabled The workqueue is enabled when the appropriate driver is loaded and disabled when the driver is removed. When the driver is removed it assumes that the workqueue was enabled successfully and proceeds to free allocations made during workqueue enabling. Failure during workqueue enabling does not prevent the driver from being loaded. This is because the error path within drv_enable_wq() returns success unless a second failure is encountered during the error path. By returning success it is possible to load the driver even if the workqueue cannot be enabled and allocations that do not exist are attempted to be freed during driver remove. Some examples of problematic flows: (a) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_unmap_portal() is called on error exit path, but drv_enable_wq() returns 0 because idxd_wq_disable() succeeds. The driver is thus loaded successfully. idxd_dmaengine_drv_remove()->drv_disable_wq()->idxd_wq_unmap_portal() Above flow on driver unload triggers the WARN in devm_iounmap() because the device resource has already been removed during error path of drv_enable_wq(). (b) idxd_dmaengine_drv_probe() -> drv_enable_wq() -> idxd_wq_request_irq(): In above flow, if idxd_wq_request_irq() fails then idxd_wq_init_percpu_ref() is never called to initialize the percpu counter, yet the driver loads successfully because drv_enable_wq() returns 0. idxd_dmaengine_drv_remove()->__idxd_wq_quiesce()->percpu_ref_kill(): Above flow on driver unload triggers a BUG when attempting to drop the initial ref of the uninitialized percpu ref: BUG: kernel NULL pointer dereference, address: 0000000000000010 Fix the drv_enable_wq() error path by returning the original error that indicates failure of workqueue enabling. This ensures that the probe fails when an error is encountered and the driver remove paths are only attempted when the workqueue was enabled successfully. | ["https://git.kernel.org/stable/c/0f150134dd795ffcd60b798a85ab737d8d010fb7","https://git.kernel.org/stable/c/99dc4520b74e7ca8e9dc9abe37a0b10b49467960","https://git.kernel.org/stable/c/b51b75f0604f17c0f6f3b6f68f1a521a5cc6b04f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48903 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix relocation crash due to premature return from btrfs_commit_transaction() We are seeing crashes similar to the following trace: [38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs] [38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54 [38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs] [38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206 [38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14 [38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360 [38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000 [38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800 [38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360 [38.987146] FS: 00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000 [38.988662] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0 [38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [38.992528] Call Trace: [38.992854] <TASK> [38.993148] btrfs_relocate_chunk+0x27/0xe0 [btrfs] [38.993941] btrfs_balance+0x78e/0xea0 [btrfs] [38.994801] ? vsnprintf+0x33c/0x520 [38.995368] ? __kmalloc_track_caller+0x351/0x440 [38.996198] btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs] [38.997084] btrfs_ioctl+0x11b0/0x2da0 [btrfs] [38.997867] ? mod_objcg_state+0xee/0x340 [38.998552] ? seq_release+0x24/0x30 [38.999184] ? proc_nr_files+0x30/0x30 [38.999654] ? call_rcu+0xc8/0x2f0 [39.000228] ? __x64_sys_ioctl+0x84/0xc0 [39.000872] ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs] [39.001973] __x64_sys_ioctl+0x84/0xc0 [39.002566] do_syscall_64+0x3a/0x80 [39.003011] entry_SYSCALL_64_after_hwframe+0x44/0xae [39.003735] RIP: 0033:0x7f11c166959b [39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b [39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003 [39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0 [39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3 [39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001 [39.015040] </TASK> [39.015418] ---[ end trace 0000000000000000 ]--- [43.131559] ------------[ cut here ]------------ [43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717! [43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI [43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G W 5.17.0-rc4 #54 [43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs] [43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246 [43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001 [43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff [43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50 [43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000 [43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000 [43.145686] FS: 00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000 [43.146808] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0 [43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000 ---truncated--- | ["https://git.kernel.org/stable/c/5fd76bf31ccfecc06e2e6b29f8c809e934085b99","https://git.kernel.org/stable/c/725a6ac389b182261af174176e561a36b0f39ffc","https://git.kernel.org/stable/c/a4378947ae39f08c6ae4c6a87ccdebc981a7bbcb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48906 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: Correctly set DATA_FIN timeout when number of retransmits is large Syzkaller with UBSAN uncovered a scenario where a large number of DATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FIN timeout calculation: ================================================================================ UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29 shift exponent 32 is too large for 32-bit type 'unsigned int' CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline] __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 worker_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4/0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> ================================================================================ This change limits the maximum timeout by limiting the size of the shift, which keeps all intermediate values in-bounds. | ["https://git.kernel.org/stable/c/03ae283bd71f761feae3f402668d698b393b0e79","https://git.kernel.org/stable/c/0c3f34beb459753f9f80d0cc14c1b50ab615c631","https://git.kernel.org/stable/c/877d11f0332cd2160e19e3313e262754c321fa36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48907 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: auxdisplay: lcd2s: Fix memory leak in ->remove() Once allocated the struct lcd2s_data is never freed. Fix the memory leak by switching to devm_kzalloc(). | ["https://git.kernel.org/stable/c/3585ed5f9b11a6094dd991d76a1541e5d03b986a","https://git.kernel.org/stable/c/5d53cd33f4253aa4cf02bf7e670b3c6a99674351","https://git.kernel.org/stable/c/898c0a15425a5bcaa8d44bd436eae5afd2483796"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48916 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix double list_add when enabling VMD in scalable mode When enabling VMD and IOMMU scalable mode, the following kernel panic call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids CPU) during booting: pci 0000:59:00.5: Adding to iommu group 42 ... vmd 0000:59:00.5: PCI host bridge to bus 10000:80 pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:01.0: enabling Extended Tags pci 10000:80:01.0: PME# supported from D0 D3hot D3cold pci 10000:80:01.0: DMAR: Setup RID2PASID failed pci 10000:80:01.0: Failed to add to iommu group 42: -16 pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] pci 10000:80:03.0: enabling Extended Tags pci 10000:80:03.0: PME# supported from D0 D3hot D3cold ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 Workqueue: events work_for_cpu_fn RIP: 0010:__list_add_valid.cold+0x26/0x3f Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 9e e8 8b b1 fe RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> intel_pasid_alloc_table+0x9c/0x1d0 dmar_insert_one_dev_info+0x423/0x540 ? device_to_iommu+0x12d/0x2f0 intel_iommu_attach_device+0x116/0x290 __iommu_attach_device+0x1a/0x90 iommu_group_add_device+0x190/0x2c0 __iommu_probe_device+0x13e/0x250 iommu_probe_device+0x24/0x150 iommu_bus_notifier+0x69/0x90 blocking_notifier_call_chain+0x5a/0x80 device_add+0x3db/0x7b0 ? arch_memremap_can_ram_remap+0x19/0x50 ? memremap+0x75/0x140 pci_device_add+0x193/0x1d0 pci_scan_single_device+0xb9/0xf0 pci_scan_slot+0x4c/0x110 pci_scan_child_bus_extend+0x3a/0x290 vmd_enable_domain.constprop.0+0x63e/0x820 vmd_probe+0x163/0x190 local_pci_probe+0x42/0x80 work_for_cpu_fn+0x13/0x20 process_one_work+0x1e2/0x3b0 worker_thread+0x1c4/0x3a0 ? rescuer_thread+0x370/0x370 kthread+0xc7/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- ... Kernel panic - not syncing: Fatal exception Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) ---[ end Kernel panic - not syncing: Fatal exception ]--- The following 'lspci' output shows devices '10000:80:*' are subdevices of the VMD device 0000:59:00.5: $ lspci ... 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) ... 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] 10000:82:00 ---truncated--- | ["https://git.kernel.org/stable/c/2aaa085bd012a83be7104356301828585a2253ed","https://git.kernel.org/stable/c/b00833768e170a31af09268f7ab96aecfcca9623","https://git.kernel.org/stable/c/d5ad4214d9c6c6e465c192789020a091282dfee7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48944 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched: Fix yet more sched_fork() races Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash. Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit. | ["https://git.kernel.org/stable/c/3411613611a5cddf7e80908010dc87cb527dd13b","https://git.kernel.org/stable/c/b1e8206582f9d680cff7d04828708c8b6ab32957","https://git.kernel.org/stable/c/c65cfd89cef669d90c59f3bf150af6458137a04f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49019 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: nixge: fix NULL dereference In function nixge_hw_dma_bd_release() dereference of NULL pointer priv->rx_bd_v is possible for the case of its allocation failure in nixge_hw_dma_bd_init(). Move for() loop with priv->rx_bd_v dereference under the check for its validity. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/45752af0247589e6d3dede577415bfe117b4392c","https://git.kernel.org/stable/c/80e82f7b440b65cf131dce10f487dc73a7046e6b","https://git.kernel.org/stable/c/910c0264b64ef2dad8887714a7c56c93e39a0ed3","https://git.kernel.org/stable/c/9256db4e45e8b497b0e993cc3ed4ad08eb2389b6","https://git.kernel.org/stable/c/9c584d6d9cfb935dce8fc81a4c26debac0a3049b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50093 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] <TASK> [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ] | ["https://git.kernel.org/stable/c/434525a864136c928b54fd2512b4c0167c207463","https://git.kernel.org/stable/c/8403021b6f32d68a7e3a6b8428ecaf5c153a9974","https://git.kernel.org/stable/c/99ca0b57e49fb73624eede1c4396d9e3d10ccf14","https://git.kernel.org/stable/c/b4ab78f4adeaf6c98be5d375518dd4fb666eac5e","https://git.kernel.org/stable/c/dd64ea03375618684477f946be4f5e253f8676c2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52903 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path. | ["https://git.kernel.org/stable/c/544d163d659d45a206d8929370d5a2984e546cb7","https://git.kernel.org/stable/c/7fc3990dad04a677606337ebc61964094d6cb41b","https://git.kernel.org/stable/c/de77faee280163ff03b7ab64af6c9d779a43d4c4","https://git.kernel.org/stable/c/ed4629d1e968359fbb91d0a3780b1e86a2c08845"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49896 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/0167d570f6a0b38689c4a0e50bf79c518d827500","https://git.kernel.org/stable/c/14db8692afe1aa2143b673856bb603713d8ea93f","https://git.kernel.org/stable/c/35ff747c86767937ee1e0ca987545b7eed7a0810","https://git.kernel.org/stable/c/3944d226f55235a960d8f1135927f95e9801be12","https://git.kernel.org/stable/c/42d31a33643813cce55ee1ebbad3a2d0d24a08e0","https://git.kernel.org/stable/c/471c53350ab83e47a2a117c2738ce0363785976e","https://git.kernel.org/stable/c/5b4b13e678b15975055f4ff1ce4cf0ce4c19b6c4","https://git.kernel.org/stable/c/e41a291e1bef1153bba091b6580ecc7affc53c82","https://git.kernel.org/stable/c/e8da54b7f8a17e44e67ea6d1037f35450af28115"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages. | ["https://git.kernel.org/stable/c/058aa89b3318be3d66a103ba7c68d717561e1dc6","https://git.kernel.org/stable/c/2451e5917c56be45d4add786e2a059dd9c2c37c4","https://git.kernel.org/stable/c/25d2a3ff02f22e215ce53355619df10cc5faa7ab","https://git.kernel.org/stable/c/35b91f15f44ce3c01eba058ccb864bb04743e792","https://git.kernel.org/stable/c/4a7bf6a01fb441009a6698179a739957efd88e38","https://git.kernel.org/stable/c/7fff9a9f866e99931cf6fa260288e55d01626582","https://git.kernel.org/stable/c/cb0eb10558802764f07de1dc439c4609e27cb4f0","https://git.kernel.org/stable/c/d64ff0d2306713ff084d4b09f84ed1a8c75ecc32","https://git.kernel.org/stable/c/d76b9a4c283c7535ae7c7c9b14984e75402951e1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49938 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it. | ["https://git.kernel.org/stable/c/012ae530afa0785102360de452745d33c99a321b","https://git.kernel.org/stable/c/2c230210ec0ae6ed08306ac70dc21c24b817bb95","https://git.kernel.org/stable/c/6a875220670475d9247e576c15dc29823100a4e4","https://git.kernel.org/stable/c/94745807f3ebd379f23865e6dab196f220664179","https://git.kernel.org/stable/c/a9f4e28e8adaf0715bd4e01462af0a52ee46b01f","https://git.kernel.org/stable/c/b02eb7c86ff2ef1411c3095ec8a52b13f68db04f","https://git.kernel.org/stable/c/d1f2fbc6a769081503f6ffedbb5cd1ac497f0e77","https://git.kernel.org/stable/c/e37e348835032d6940ec89308cc8996ded691d2d","https://git.kernel.org/stable/c/e6b9bf32e0695e4f374674002de0527d2a6768eb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49962 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ] | ["https://git.kernel.org/stable/c/1c9b8775062f8d854a80caf186af57fc617d454c","https://git.kernel.org/stable/c/402b4c6b7500c7cca6972d2456a4a422801035b5","https://git.kernel.org/stable/c/4588ea78d3904bebb613b0bb025669e75800f546","https://git.kernel.org/stable/c/4669da66ebc5b09881487f30669b0fcdb462188e","https://git.kernel.org/stable/c/a5242874488eba2b9062985bf13743c029821330","https://git.kernel.org/stable/c/a907c113a8b66972f15f084d7dff960207b1f71d","https://git.kernel.org/stable/c/ae5d4c7e76ba393d20366dfea1f39f24560ffb1d","https://git.kernel.org/stable/c/cbb67e245dacd02b5e1d82733892647df1523982","https://git.kernel.org/stable/c/f282db38953ad71dd4f3f8877a4e1d37e580e30a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50008 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan->tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex] | ["https://git.kernel.org/stable/c/17199b69a84798efffc475040fbef44374ef1de1","https://git.kernel.org/stable/c/1756918f51e9ab247a0f4782cc28853c2bb457c1","https://git.kernel.org/stable/c/498365e52bebcbc36a93279fe7e9d6aec8479cee","https://git.kernel.org/stable/c/71267bd4e8c752d7af6c6b96bb83984a6a95273d","https://git.kernel.org/stable/c/a3a12c30f9510f3753286fadbc6cdb7dad78c1d5","https://git.kernel.org/stable/c/b55c8848fdc81514ec047b2a0ec782ffe9ab5323","https://git.kernel.org/stable/c/e59bdb1ba594104cd0ee0af3ee9e4435d842a8fe","https://git.kernel.org/stable/c/f9310a6704bf52e2493480edea896e1f9b795d40","https://git.kernel.org/stable/c/fef7b51f22cf2049b0ca6740adeb0ba6f2e671dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38661 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/ap: Fix crash in AP internal function modify_bitmap() A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oops occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value (like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX. The fix is simple: use unsigned long values for the internal variables. The correct checks are already in place in the function but a simple int for the internal variables was used with the possibility to overflow. | ["https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558","https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056","https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9","https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0","https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05","https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6","https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad","https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9","https://git.kernel.org/stable/c/2062e3f1f2374102f8014d7ca286b9aa527bd558","https://git.kernel.org/stable/c/4c0bfb4e867c1ec6616a5049bd3618021e127056","https://git.kernel.org/stable/c/67011123453b91ec03671d40712fa213e94a01b9","https://git.kernel.org/stable/c/7360cef95aa1ea2b5efb7b5e2ed32e941664e1f0","https://git.kernel.org/stable/c/7c72af16abf2ec7520407098360bbba312289e05","https://git.kernel.org/stable/c/7dabe54a016defe11bb2a278cd9f1ff6db3feba6","https://git.kernel.org/stable/c/8c5f5911c1b13170d3404eb992c6a0deaa8d81ad","https://git.kernel.org/stable/c/d4f9d5a99a3fd1b1c691b7a1a6f8f3f25f4116c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47520 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.0.11. Missing offset validation in drivers/net/wireless/microchip/wilc1000/hif.c in the WILC1000 wireless driver can trigger an out-of-bounds read when parsing a Robust Security Network (RSN) information element from a Netlink packet. | ["https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/","https://github.com/torvalds/linux/commit/cd21d99e595ec1d8721e1058dcdd4f1f7de1d793","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/r/20221123153543.8568-2-philipturnbull%40github.com","https://security.netapp.com/advisory/ntap-20230113-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49368 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: out of bounds read in mtk_hwlro_get_fdir_entry() The "fsp->location" variable comes from user via ethtool_get_rxnfc(). Check that it is valid to prevent an out of bounds read. | ["https://git.kernel.org/stable/c/0b238f75b65ed4462ef4cdfa718cac0ac7fce3b8","https://git.kernel.org/stable/c/2bd1faedb74dc2a2be3972abcd4239b75a3e7b00","https://git.kernel.org/stable/c/4cde554c70d7397cfa2e4116bacb4accdfb6fd48","https://git.kernel.org/stable/c/5ba81f82607ead85fe36f50869fc4f5661359ab8","https://git.kernel.org/stable/c/657e7174603f0aab2cdedc64ac81edffd2a87afe","https://git.kernel.org/stable/c/71ae30662ec610b92644d13f79c78f76f17873b3","https://git.kernel.org/stable/c/b24ca1cf846273361d5bd73a35de95a486a54b6d","https://git.kernel.org/stable/c/b4f0e57ea0d867aacffad7999527e48bd4ea9293","https://git.kernel.org/stable/c/e7e7104e2d5ddf3806a28695670f21bef471f1e1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49395 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: um: Fix out-of-bounds read in LDT setup syscall_stub_data() expects the data_count parameter to be the number of longs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ================================================================== | ["https://git.kernel.org/stable/c/10995a382271254bd276627ec74136da4a23c4a6","https://git.kernel.org/stable/c/24ca648bf5f72ed8878cf09b5d4431935779681e","https://git.kernel.org/stable/c/2a4a62a14be1947fa945c5c11ebf67326381a568","https://git.kernel.org/stable/c/3549ab4b962cf619e8c55484a0d870a34b3f845f","https://git.kernel.org/stable/c/668ca34a428d6ffc0f99a1a6a9b661a288d4183b","https://git.kernel.org/stable/c/91e5ba2af2d729d5126aefd5aa3eadc69b8426e5","https://git.kernel.org/stable/c/9caad70819aef3431abaf73ba5163b55b161aba0","https://git.kernel.org/stable/c/cf0dabc37446c5ee538ae7b4c467ab0e53fa5463","https://git.kernel.org/stable/c/ef1dc929a1e5fa1b2d842256db9fb8710d3be910"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49218 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/dp: Fix OOB read when handling Post Cursor2 register The link_status array was not large enough to read the Adjust Request Post Cursor2 register, so remove the common helper function to avoid an OOB read, found with a -Warray-bounds build: drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor': drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds] 59 | return link_status[r - DP_LANE0_1_STATUS]; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status' 147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE], | ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Replace the only user of the helper with an open-coded fetch and decode, similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c. | ["https://git.kernel.org/stable/c/a2151490cc6c57b368d7974ffd447a8b36ade639","https://git.kernel.org/stable/c/aeaed9a9fe694f8b1462fb81e2d33298c929180b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26585 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do. | ["https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d","https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146","https://git.kernel.org/stable/c/dd32621f19243f89ce830919496a5dcc2158aa33","https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb","https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57","https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d","https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146","https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb","https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52749 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: Fix null dereference on suspend A race condition exists where a synchronous (noqueue) transfer can be active during a system suspend. This can cause a null pointer dereference exception to occur when the system resumes. Example order of events leading to the exception: 1. spi_sync() calls __spi_transfer_message_noqueue() which sets ctlr->cur_msg 2. Spi transfer begins via spi_transfer_one_message() 3. System is suspended interrupting the transfer context 4. System is resumed 6. spi_controller_resume() calls spi_start_queue() which resets cur_msg to NULL 7. Spi transfer context resumes and spi_finalize_current_message() is called which dereferences cur_msg (which is now NULL) Wait for synchronous transfers to complete before suspending by acquiring the bus mutex and setting/checking a suspend flag. | ["https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068","https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e","https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37","https://git.kernel.org/stable/c/4ec4508db97502a12daee88c74782e8d35ced068","https://git.kernel.org/stable/c/96474ea47dc67b0704392d59192b233c8197db0e","https://git.kernel.org/stable/c/bef4a48f4ef798c4feddf045d49e53c8a97d5e37"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42227 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix overlapping copy within dml_core_mode_programming [WHY] &mode_lib->mp.Watermark and &locals->Watermark are the same address. memcpy may lead to unexpected behavior. [HOW] memmove should be used. | ["https://git.kernel.org/stable/c/9342da15f2491d8600eca89c8e0da08876fb969b","https://git.kernel.org/stable/c/f1fd8a0a54e6d23a6d16ee29159f247862460fd1","https://git.kernel.org/stable/c/9342da15f2491d8600eca89c8e0da08876fb969b","https://git.kernel.org/stable/c/f1fd8a0a54e6d23a6d16ee29159f247862460fd1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3577 | High | fixed |
|
An out-of-bounds memory write flaw was found in the Linux kernel’s Kid-friendly Wired Controller driver. This flaw allows a local user to crash or potentially escalate their privileges on the system. It is in bigben_probe of drivers/hid/hid-bigbenff.c. The reason is incorrect assumption - bigben devices all have inputs. However, malicious devices can break this assumption, leaking to out-of-bound write. | ["https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next\u0026id=9d64d2405f7d30d49818f6682acd0392348f0fdb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db","https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/commit/?h=char-misc-next\u0026id=9d64d2405f7d30d49818f6682acd0392348f0fdb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=945a9a8e448b65bec055d37eba58f711b39f66f0","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc4ef9d5724973193bfa5ebed181dba6de3a56db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3610 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Flaw in the error handling of bound chains causes a use-after-free in the abort path of NFT_MSG_NEWRULE. The vulnerability requires CAP_NET_ADMIN to be triggered. We recommend upgrading past commit 4bedf9eee016286c835e3d8fa981ddece5338795. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795","https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5461","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=4bedf9eee016286c835e3d8fa981ddece5338795","https://kernel.dance/4bedf9eee016286c835e3d8fa981ddece5338795","https://lists.debian.org/debian-lts-announce/2023/08/msg00001.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5461"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2124 | High | fixed |
|
An out-of-bounds memory access flaw was found in the Linux kernel’s XFS file system in how a user restores an XFS image after failure (with a dirty log journal). This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1\u0026id=22ed903eee23a5b174e240f1cdfa9acf393a5210","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230622-0010/","https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/xfs/xfs_buf_item_recover.c?h=v6.4-rc1\u0026id=22ed903eee23a5b174e240f1cdfa9acf393a5210","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230622-0010/","https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994e","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3424 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2132640","https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230406-0005/","https://www.spinics.net/lists/kernel/msg4518970.html","https://bugzilla.redhat.com/show_bug.cgi?id=2132640","https://github.com/torvalds/linux/commit/643a16a0eb1d6ac23744bb6e90a00fc21148a9dc","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221019031445.901570-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230406-0005/","https://www.spinics.net/lists/kernel/msg4518970.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-36123 | High | fixed |
|
The Linux kernel before 5.18.13 lacks a certain clear operation for the block starting symbol (.bss). This allows Xen PV guest OS users to cause a denial of service or gain privileges. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13","https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md","https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0","https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884","https://security.netapp.com/advisory/ntap-20220901-0003/","https://sick.codes/sick-2022-128","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.13","https://github.com/sickcodes/security/blob/master/advisories/SICK-2022-128.md","https://github.com/torvalds/linux/commit/74a0032b8524ee2bd4443128c0bf9775928680b0","https://github.com/torvalds/linux/commit/96e8fc5818686d4a1591bb6907e7fdb64ef29884","https://security.netapp.com/advisory/ntap-20220901-0003/","https://sick.codes/sick-2022-128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21928 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove() The system can experience a random crash a few minutes after the driver is removed. This issue occurs due to improper handling of memory freeing in the ishtp_hid_remove() function. The function currently frees the `driver_data` directly within the loop that destroys the HID devices, which can lead to accessing freed memory. Specifically, `hid_destroy_device()` uses `driver_data` when it calls `hid_ishtp_set_feature()` to power off the sensor, so freeing `driver_data` beforehand can result in accessing invalid memory. This patch resolves the issue by storing the `driver_data` in a temporary variable before calling `hid_destroy_device()`, and then freeing the `driver_data` after the device is destroyed. | ["https://git.kernel.org/stable/c/01b18a330cda61cc21423a7d1af92cf31ded8f60","https://git.kernel.org/stable/c/07583a0010696a17fb0942e0b499a62785c5fc9f","https://git.kernel.org/stable/c/0c1fb475ef999d6c22fc3f963fdf20cb3ed1b03d","https://git.kernel.org/stable/c/560f4d1299342504a6ab8a47f575b5e6b8345ada","https://git.kernel.org/stable/c/cf1a6015d2f6b1f0afaa0fd6a0124ff2c7943394","https://git.kernel.org/stable/c/d3faae7f42181865c799d88c5054176f38ae4625","https://git.kernel.org/stable/c/dea6a349bcaf243fff95dfd0428a26be6a0fb44e","https://git.kernel.org/stable/c/eb0695d87a81e7c1f0509b7d8ee7c65fbc26aec9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21934 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rapidio: fix an API misues when rio_add_net() fails rio_add_net() calls device_register() and fails when device_register() fails. Thus, put_device() should be used rather than kfree(). Add "mport->net = NULL;" to avoid a use after free issue. | ["https://git.kernel.org/stable/c/22e4977141dfc6d109bf29b495bf2187b4250990","https://git.kernel.org/stable/c/2537f01d57f08c527e40bbb5862aa6ff43344898","https://git.kernel.org/stable/c/88ddad53e4cfb6de861c6d4fb7b25427f46baed5","https://git.kernel.org/stable/c/a5f5e520e8fbc6294020ff8afa36f684d92c6e6a","https://git.kernel.org/stable/c/b2ef51c74b0171fde7eb69b6152d3d2f743ef269","https://git.kernel.org/stable/c/cdd9f58f7fe41a55fae4305ea51fc234769fd466","https://git.kernel.org/stable/c/d4ec862ce80f64db923a1d942b5d11cf6fc87d36","https://git.kernel.org/stable/c/f0aa4ee1cbbf7789907e5a3f6810de01c146c211"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-1085 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. The nft_setelem_catchall_deactivate() function checks whether the catch-all set element is active in the current generation instead of the next generation before freeing it, but only flags it inactive in the next generation, making it possible to free the element multiple times, leading to a double free vulnerability. We recommend upgrading past commit b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7","https://kernel.dance/b1db244ffd041a49ecc9618e8feb6b5c1afcdaa7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21718 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: rose: fix timer races against user threads Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread. Add a check and rearm the timers if needed. BUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174 call_timer_fn+0x187/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430 run_timer_base kernel/time/timer.c:2439 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ> | ["https://git.kernel.org/stable/c/0d5bca3be27bfcf8f980f2fed49b6cbb7dafe4a1","https://git.kernel.org/stable/c/1409b45d4690308c502c6caf22f01c3c205b4717","https://git.kernel.org/stable/c/1992fb261c90e9827cf5dc3115d89bb0853252c9","https://git.kernel.org/stable/c/51c128ba038cf1b79d605cbee325919b45ab95a5","https://git.kernel.org/stable/c/52f5aff33ca73b2c2fa93f40a3de308012e63cf4","https://git.kernel.org/stable/c/58051a284ac18a3bb815aac6289a679903ddcc3f","https://git.kernel.org/stable/c/5de7665e0a0746b5ad7943554b34db8f8614a196","https://git.kernel.org/stable/c/f55c88e3ca5939a6a8a329024aed8f3d98eea8e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2006 | High | fixed |
|
A race condition was found in the Linux kernel's RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2189112","https://github.com/torvalds/linux/commit/3bcd6c7eaa53","https://security.netapp.com/advisory/ntap-20230609-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-439/","https://bugzilla.redhat.com/show_bug.cgi?id=2189112","https://github.com/torvalds/linux/commit/3bcd6c7eaa53","https://security.netapp.com/advisory/ntap-20230609-0004/","https://www.zerodayinitiative.com/advisories/ZDI-23-439/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48634 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: Fix BUG: sleeping function called from invalid context errors gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex. The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors. Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set. This fixes the following WARN/stacktrace: [ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0 [ 512.124300] ? do_syscall_64+0x67/0x80 [ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647] </TASK> | ["https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281","https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd","https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd","https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b","https://git.kernel.org/stable/c/63e37a79f7bd939314997e29c2f5a9f0ef184281","https://git.kernel.org/stable/c/a6ed7624bf4d0a32f2631e74828bca7b7bf15afd","https://git.kernel.org/stable/c/c5812807e416618477d1bb0049727ce8bb8292fd","https://git.kernel.org/stable/c/e5ae504c8623476e13032670f1a6d6344d53ec9b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3534 | High | N/A | A vulnerability classified as critical has been found in Linux Kernel. Affected is the function btf_dump_name_dups of the file tools/lib/bpf/btf_dump.c of the component libbpf. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211032. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93c660ca40b5d2f7c1b1626e955a8e9fa30e0749","https://vuldb.com/?id.211032","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93c660ca40b5d2f7c1b1626e955a8e9fa30e0749","https://vuldb.com/?id.211032"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49965 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series "Misc fixes for ocfs2_read_blocks", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock. | ["https://git.kernel.org/stable/c/39a88623af3f1c686bf6db1e677ed865ffe6fccc","https://git.kernel.org/stable/c/3f1ca6ba5452d53c598a45d21267a2c0c221eef3","https://git.kernel.org/stable/c/5245f109b4afb6595360d4c180d483a6d2009a59","https://git.kernel.org/stable/c/81aba693b129e82e11bb54f569504d943d018de9","https://git.kernel.org/stable/c/84543da867c967edffd5065fa910ebf56aaae49d","https://git.kernel.org/stable/c/9753bcb17b36c9add9b32c61766ddf8d2d161911","https://git.kernel.org/stable/c/c03a82b4a0c935774afa01fd6d128b444fd930a1","https://git.kernel.org/stable/c/df4f20fc3673cee11abf2c571987a95733cb638d","https://git.kernel.org/stable/c/f55a33fe0fb5274ef185fd61947cf142138958af"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49867 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated--- | ["https://git.kernel.org/stable/c/41fd1e94066a815a7ab0a7025359e9b40e4b3576","https://git.kernel.org/stable/c/4c98fe0dfa2ae83c4631699695506d8941db4bfe","https://git.kernel.org/stable/c/65d11eb276836d49003a8060cf31fa2284ad1047","https://git.kernel.org/stable/c/70b60c8d9b42763d6629e44f448aa5d8ae477d61","https://git.kernel.org/stable/c/9da40aea63f8769f28afb91aea0fac4cf6fbbb65","https://git.kernel.org/stable/c/a71349b692ab34ea197949e13e3cc42570fe73d9","https://git.kernel.org/stable/c/bf0de0f9a0544c11f96f93206da04ab87dcea1f4","https://git.kernel.org/stable/c/cd686dfff63f27d712877aef5b962fbf6b8bc264","https://git.kernel.org/stable/c/ed87190e9d9c80aad220fb6b0b03a84d22e2c95b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0171 | Medium | fixed |
|
A flaw was found in the Linux kernel. The existing KVM SEV API has a vulnerability that allows a non-root (host) user-level application to crash the host kernel by creating a confidential guest VM instance in AMD CPU that supports Secure Encrypted Virtualization (SEV). | ["https://access.redhat.com/security/cve/CVE-2022-0171","https://bugzilla.redhat.com/show_bug.cgi?id=2038940","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=683412ccf61294d727ead4a73d97397396e69a6b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257","https://access.redhat.com/security/cve/CVE-2022-0171","https://bugzilla.redhat.com/show_bug.cgi?id=2038940","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=683412ccf61294d727ead4a73d97397396e69a6b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21898 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ftrace: Avoid potential division by zero in function_stat_show() Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case. For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier. | ["https://git.kernel.org/stable/c/3d738b53ed6cddb68e68c9874520a4bf846163b5","https://git.kernel.org/stable/c/5b3d32f607f0478b414b16516cf27f9170cf66c8","https://git.kernel.org/stable/c/746cc474a95473591853927b3a9792a2d671155b","https://git.kernel.org/stable/c/992775227843c9376773784b8b362add44592ad7","https://git.kernel.org/stable/c/9cdac46fa7e854e587eb5f393fe491b6d7a9bdf6","https://git.kernel.org/stable/c/a1a7eb89ca0b89dc1c326eeee2596f263291aca3","https://git.kernel.org/stable/c/ca381f60a3bb7cfaa618d73ca411610bd7fc3149","https://git.kernel.org/stable/c/f58a3f8e284d0bdf94164a8e61cd4e70d337a1a3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: caif_virtio: fix wrong pointer check in cfv_probe() del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checked for NULL before calling it, not cfv->vdev. Also the current implementation is redundant because the pointer cfv->vdev is dereferenced before it is checked for NULL. Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev before calling del_vqs(). | ["https://git.kernel.org/stable/c/29e0cd296c87240278e2f7ea4cf3f496b60c03af","https://git.kernel.org/stable/c/56cddf71cce3b15b078e937fadab29962b6f6643","https://git.kernel.org/stable/c/597c27e5f04cb50e56cc9aeda75d3e42b6b89c3e","https://git.kernel.org/stable/c/7b5fe58959822e6cfa884327cabba6be3b01883d","https://git.kernel.org/stable/c/8e4e08ca4cc634b337bb74bc9a70758fdeda0bcb","https://git.kernel.org/stable/c/90d302619ee7ce5ed0c69c29c290bdccfde66418","https://git.kernel.org/stable/c/990fff6980d0c1693d60a812f58dbf93eab0473f","https://git.kernel.org/stable/c/a466fd7e9fafd975949e5945e2f70c33a94b1a70"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21922 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ppp: Fix KMSAN uninit-value warning with bpf Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filter. The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' Wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver. As you can see the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet. Then it read the first byte of the first 2 bytes to determine the direction. The issue is that only the first byte indicating direction is initialized in current ppp driver code while the second byte is not initialized. For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN. [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 | ["https://git.kernel.org/stable/c/1eacd47636a9de5bee25d9d5962dc538a82d9f0b","https://git.kernel.org/stable/c/2f591cb158807bdcf424f66f1fbfa6e4e50f3757","https://git.kernel.org/stable/c/3de809a768464528762757e433cd50de35bcb3c1","https://git.kernel.org/stable/c/4c2d14c40a68678d885eab4008a0129646805bae","https://git.kernel.org/stable/c/4e2191b0fd0c064d37b0db67396216f2d4787e0f","https://git.kernel.org/stable/c/8aa8a40c766b3945b40565a70349d5581458ff63","https://git.kernel.org/stable/c/c036f5f2680cbdabdbbace86baee3c83721634d6","https://git.kernel.org/stable/c/d685096c8129c9a92689975193e268945fd21dbf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21948 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: appleir: Fix potential NULL dereference at raw event handle Syzkaller reports a NULL pointer dereference issue in input_event(). BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline] BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline] BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395 Read of size 8 at addr 0000000000000028 by task syz-executor199/2949 CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> This happens due to the malformed report items sent by the emulated device which results in a report, that has no fields, being added to the report list. Due to this appleir_input_configured() is never called, hidinput_connect() fails which results in the HID_CLAIMED_INPUT flag is not being set. However, it does not make appleir_probe() fail and lets the event callback to be called without the associated input device. Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook early if the driver didn't claim any input_dev for some reason. Moreover, some other hid drivers accessing input_dev in their event callbacks do have similar checks, too. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/0df1ac8ee417ad76760ff076faa4518a4d861894","https://git.kernel.org/stable/c/2ff5baa9b5275e3acafdf7f2089f74cccb2f38d1","https://git.kernel.org/stable/c/68cdf6710f228dfd74f66ec61fbe636da2646a73","https://git.kernel.org/stable/c/6db423b00940b05df2a1265d3c7eabafe9f1734c","https://git.kernel.org/stable/c/8d39eb8c5e14f2f0f441eed832ef8a7b654e6fee","https://git.kernel.org/stable/c/b1d95d733cd6e74f595653daddcfc357bea461e8","https://git.kernel.org/stable/c/d335fce8b88b2353f4bb20c631698e20384e3610","https://git.kernel.org/stable/c/fc69e2c3219d433caabba4b5d6371ba726a4b37f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21957 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla1280: Fix kernel oops when debug level > 2 A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. I think its clear from the code that the intention here is sg_dma_len(s) not length of sg_next(s) when printing the debug info. | ["https://git.kernel.org/stable/c/11a8dac1177a596648a020a7f3708257a2f95fee","https://git.kernel.org/stable/c/24602e2664c515a4f2950d7b52c3d5997463418c","https://git.kernel.org/stable/c/5233e3235dec3065ccc632729675575dbe3c6b8a","https://git.kernel.org/stable/c/7ac2473e727d67a38266b2b7e55c752402ab588c","https://git.kernel.org/stable/c/af71ba921d08c241a817010f96458dc5e5e26762","https://git.kernel.org/stable/c/afa27b7c17a48e01546ccaad0ab017ad0496a522","https://git.kernel.org/stable/c/c737e2a5fb7f90b96a96121da1b50a9c74ae9b8c","https://git.kernel.org/stable/c/ea371d1cdefb0951c7127a33bcd7eb931cf44571"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21959 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree() Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbage collection confirm race"), `cpu` and `jiffies32` were introduced to the struct nf_conncount_tuple. The commit made nf_conncount_add() initialize `conn->cpu` and `conn->jiffies32` when allocating the struct. In contrast, count_tree() was not changed to initialize them. By commit 34848d5c896e ("netfilter: nf_conncount: Split insert and traversal"), count_tree() was split and the relevant allocation code now resides in insert_tree(). Initialize `conn->cpu` and `conn->jiffies32` in insert_tree(). BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline] BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8e Uninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip ---truncated--- | ["https://git.kernel.org/stable/c/2a154ce766b995494e88d8d117fa82cc6b73dd87","https://git.kernel.org/stable/c/2db5baaf047a7c8d6ed5e2cc657b7854e155b7fc","https://git.kernel.org/stable/c/a62a25c6ad58fae997f48a0749afeda1c252ae51","https://git.kernel.org/stable/c/d653bfeb07ebb3499c403404c21ac58a16531607","https://git.kernel.org/stable/c/db1e0c0856821c59a32ea3af79476bf20a6beeb2","https://git.kernel.org/stable/c/e8544a5a97bee3674e7cd6bf0f3a4af517fa9146","https://git.kernel.org/stable/c/f522229c5563b59b4240261e406779bba6754159","https://git.kernel.org/stable/c/fda50302a13701d47fbe01e1739c7a51114144fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21996 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse() On the off chance that command stream passed from userspace via ioctl() call to radeon_vce_cs_parse() is weirdly crafted and first command to execute is to encode (case 0x03000001), the function in question will attempt to call radeon_vce_cs_reloc() with size argument that has not been properly initialized. Specifically, 'size' will point to 'tmp' variable before the latter had a chance to be assigned any value. Play it safe and init 'tmp' with 0, thus ensuring that radeon_vce_cs_reloc() will catch an early error in cases like these. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. (cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68) | ["https://git.kernel.org/stable/c/0effb378ebce52b897f85cd7f828854b8c7cb636","https://git.kernel.org/stable/c/3ce08215cad55c10a6eeeb33d3583b6cfffe3ab8","https://git.kernel.org/stable/c/5b4d9d20fd455a97920cf158dd19163b879cf65d","https://git.kernel.org/stable/c/78b07dada3f02f77762d0755a96d35f53b02be69","https://git.kernel.org/stable/c/9b2da9c673a0da1359a2151f7ce773e2f77d71a9","https://git.kernel.org/stable/c/dd1801aa01bba1760357f2a641346ae149686713","https://git.kernel.org/stable/c/dd8689b52a24807c2d5ce0a17cb26dc87f75235c","https://git.kernel.org/stable/c/f5e049028124f755283f2c07e7a3708361ed1dc8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50142 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xfrm: validate new SA's prefixlen using SA family when sel.family is unset This expands the validation introduced in commit 07bf7908950a ("xfrm: Validate address prefix lengths in the xfrm selector.") syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INET Because of the AF_UNSPEC selector, verify_newsa_info doesn't put limits on prefixlen_{s,d}. But then copy_from_user_state sets x->sel.family to usersa.family (AF_INET). Do the same conversion in verify_newsa_info before validating prefixlen_{s,d}, since that's how prefixlen is going to be used later on. | ["https://git.kernel.org/stable/c/2d08a6c31c65f23db71a5385ee9cf9d8f9a67a71","https://git.kernel.org/stable/c/3f0ab59e6537c6a8f9e1b355b48f9c05a76e8563","https://git.kernel.org/stable/c/401ad99a5ae7180dd9449eac104cb755f442e7f3","https://git.kernel.org/stable/c/7d9868180bd1e4cf37e7c5067362658971162366","https://git.kernel.org/stable/c/8df5cd51fd70c33aa1776e5cbcd82b0a86649d73","https://git.kernel.org/stable/c/bce1afaa212ec380bf971614f70909a27882b862","https://git.kernel.org/stable/c/e68dd80ba498265d2266b12dc3459164f4ff0c4a","https://git.kernel.org/stable/c/f31398570acf0f0804c644006f7bfa9067106b0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46795 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: unset the binding mark of a reused connection Steve French reported null pointer dereference error from sha256 lib. cifs.ko can send session setup requests on reused connection. If reused connection is used for binding session, conn->binding can still remain true and generate_preauth_hash() will not set sess->Preauth_HashValue and it will be NULL. It is used as a material to create an encryption key in ksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer dereference error from crypto_shash_update(). BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 8 PID: 429254 Comm: kworker/8:39 Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 ) Workqueue: ksmbd-io handle_ksmbd_work [ksmbd] RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] <TASK> ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? do_user_addr_fault+0x2ee/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] ? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3] _sha256_update+0x77/0xa0 [sha256_ssse3] sha256_avx2_update+0x15/0x30 [sha256_ssse3] crypto_shash_update+0x1e/0x40 hmac_update+0x12/0x20 crypto_shash_update+0x1e/0x40 generate_key+0x234/0x380 [ksmbd] generate_smb3encryptionkey+0x40/0x1c0 [ksmbd] ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd] ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd] smb2_sess_setup+0x952/0xaa0 [ksmbd] __process_request+0xa3/0x1d0 [ksmbd] __handle_ksmbd_work+0x1c4/0x2f0 [ksmbd] handle_ksmbd_work+0x2d/0xa0 [ksmbd] process_one_work+0x16c/0x350 worker_thread+0x306/0x440 ? __pfx_worker_thread+0x10/0x10 kthread+0xef/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x44/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> | ["https://git.kernel.org/stable/c/41bc256da7e47b679df87c7fc7a5b393052b9cce","https://git.kernel.org/stable/c/4c8496f44f5bb5c06cdef5eb130ab259643392a1","https://git.kernel.org/stable/c/78c5a6f1f630172b19af4912e755e1da93ef0ab5","https://git.kernel.org/stable/c/93d54a4b59c4b3d803d20aa645ab5ca71f3b3b02","https://git.kernel.org/stable/c/9914f1bd61d5e838bb1ab15a71076d37a6db65d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4244 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. Due to a race condition between nf_tables netlink control plane transaction and nft_set element garbage collection, it is possible to underflow the reference counter causing a use-after-free vulnerability. We recommend upgrading past commit 3e91b0ebd994635df2346353322ac51ce84ce6d8. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8","https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e91b0ebd994635df2346353322ac51ce84ce6d8","https://kernel.dance/3e91b0ebd994635df2346353322ac51ce84ce6d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56712 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udmabuf: fix memory leak on last export_udmabuf() error path In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a dma_buf owning the udmabuf has already been created; but the error handling in udmabuf_create() will tear down the udmabuf without doing anything about the containing dma_buf. This leaves a dma_buf in memory that contains a dangling pointer; though that doesn't seem to lead to anything bad except a memory leak. Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we can give it different error handling. Note that the shape of this code changed a lot in commit 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios"); but the memory leak seems to have existed since the introduction of udmabuf. | ["https://git.kernel.org/stable/c/c9fc8428d4255c2128da9c4d5cd92e554d0150cf","https://git.kernel.org/stable/c/f49856f525acd5bef52ae28b7da2e001bbe7439e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27019 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get() nft_unregister_obj() can concurrent with __nft_obj_type_get(), and there is not any protection when iterate over nf_tables_objects list in __nft_obj_type_get(). Therefore, there is potential data-race of nf_tables_objects list entry. Use list_for_each_entry_rcu() to iterate over nf_tables_objects list in __nft_obj_type_get(), and use rcu_read_lock() in the caller nft_obj_type_get() to protect the entire type query process. | ["https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920","https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73","https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e","https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88","https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484","https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349","https://git.kernel.org/stable/c/379bf7257bc5f2a1b1ca8514e08a871b7bf6d920","https://git.kernel.org/stable/c/4ca946b19caf655a08d5e2266d4d5526025ebb73","https://git.kernel.org/stable/c/ad333578f736d56920e090d7db1f8dec891d815e","https://git.kernel.org/stable/c/cade34279c2249eafe528564bd2e203e4ff15f88","https://git.kernel.org/stable/c/d78d867dcea69c328db30df665be5be7d0148484","https://git.kernel.org/stable/c/df7c0fb8c2b9f9cac65659332581b19682a71349"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50192 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. | ["https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff","https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a","https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe","https://git.kernel.org/stable/c/755b9532c885b8761fb135fedcd705e21e61cccb","https://git.kernel.org/stable/c/b7d7b7fc876f836f40bf48a87e07ea18756ba196","https://git.kernel.org/stable/c/d960505a869e66184fff97fb334980a5b797c7c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check] | ["https://git.kernel.org/stable/c/0bdf77be2330062b3a64f2bec39f62ab874a6796","https://git.kernel.org/stable/c/0d16f53c91111cec914f0811fcc526a2ba77b20d","https://git.kernel.org/stable/c/0d196e7589cefe207d5d41f37a0a28a1fdeeb7c6","https://git.kernel.org/stable/c/b723f96407a0a078cf75970e4dbf16b46d286a61","https://git.kernel.org/stable/c/c9b77438077d5a20c79ead95bcdaf9bd4797baaf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49866 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the "timerlat/1" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: <TASK> ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> ``` After tracing the scheduling event, it was discovered that the migration of the "timerlat/1" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline. | ["https://git.kernel.org/stable/c/322920b53dc11f9c2b33397eb3ae5bc6a175b60d","https://git.kernel.org/stable/c/829e0c9f0855f26b3ae830d17b24aec103f7e915","https://git.kernel.org/stable/c/a0d9c0cd5856191e095cf43a2e141b73945b7716","https://git.kernel.org/stable/c/a6e9849063a6c8f4cb2f652a437e44e3ed24356c","https://git.kernel.org/stable/c/ce25f33ba89d6eefef64157655d318444580fa14","https://git.kernel.org/stable/c/f72b451dc75578f644a3019c1489e9ae2c14e6c4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21905 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: limit printed string from FW file There's no guarantee here that the file is always with a NUL-termination, so reading the string may read beyond the end of the TLV. If that's the last TLV in the file, it can perhaps even read beyond the end of the file buffer. Fix that by limiting the print format to the size of the buffer we have. | ["https://git.kernel.org/stable/c/38f0d398b6d7640d223db69df022c4a232f24774","https://git.kernel.org/stable/c/47616b82f2d42ea2060334746fed9a2988d845c9","https://git.kernel.org/stable/c/59cdda202829d1d6a095d233386870a59aff986f","https://git.kernel.org/stable/c/88ed69f924638c7503644e1f8eed1e976f3ffa7a","https://git.kernel.org/stable/c/b02f8d5a71c8571ccf77f285737c566db73ef5e5","https://git.kernel.org/stable/c/c0e626f2b2390472afac52dfe72b29daf9ed8e1d","https://git.kernel.org/stable/c/e0dc2c1bef722cbf16ae557690861e5f91208129","https://git.kernel.org/stable/c/f265e6031d0bc4fc40c4619cb42466722b46eaa9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21920 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vlan: enforce underlying device type Currently, VLAN devices can be created on top of non-ethernet devices. Besides the fact that it doesn't make much sense, this also causes a bug which leaks the address of a kernel function to usermode. When creating a VLAN device, we initialize GARP (garp_init_applicant) and MRP (mrp_init_applicant) for the underlying device. As part of the initialization process, we add the multicast address of each applicant to the underlying device, by calling dev_mc_add. __dev_mc_add uses dev->addr_len to determine the length of the new multicast address. This causes an out-of-bounds read if dev->addr_len is greater than 6, since the multicast addresses provided by GARP and MRP are only 6 bytes long. This behaviour can be reproduced using the following commands: ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev lo ip l set up dev gretest ip link add link gretest name vlantest type vlan id 100 Then, the following command will display the address of garp_pdu_rcv: ip maddr show | grep 01:80:c2:00:00:21 Fix the bug by enforcing the type of the underlying device during VLAN device initialization. | ["https://git.kernel.org/stable/c/0fb7aa04c19eac4417f360a9f7611a60637bdacc","https://git.kernel.org/stable/c/30e8aee77899173a82ae5ed89f536c096f20aaeb","https://git.kernel.org/stable/c/3561442599804905c3defca241787cd4546e99a7","https://git.kernel.org/stable/c/5a515d13e15536e82c5c7c83eb6cf5bc4827fee5","https://git.kernel.org/stable/c/7f1564b2b2072b7aa1ac75350e9560a07c7a44fd","https://git.kernel.org/stable/c/b33a534610067ade2bdaf2052900aaad99701353","https://git.kernel.org/stable/c/b6c72479748b7ea09f53ed64b223cee6463dc278","https://git.kernel.org/stable/c/fa40ebef69234e39ec2d26930d045f2fb9a8cb2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21993 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic() When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message. | ["https://git.kernel.org/stable/c/07e0d99a2f701123ad3104c0f1a1e66bce74d6e5","https://git.kernel.org/stable/c/2d1eef248107bdf3d5a69d0fde04c30a79a7bf5d","https://git.kernel.org/stable/c/9bfa80c8aa4e06dff55a953c3fffbfc68a3a3b1c","https://git.kernel.org/stable/c/a858cd58dea06cf85b142673deea8c5d87f11e70","https://git.kernel.org/stable/c/b253660fac5e0e9080d2c95e3a029e1898d49afb","https://git.kernel.org/stable/c/b388e185bfad32bfed6a97a6817f74ca00a4318f","https://git.kernel.org/stable/c/c1c6e527470e5eab0b2d57bd073530fbace39eab","https://git.kernel.org/stable/c/f763c82db8166e28f45b7cc4a5398a7859665940"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1973 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel in log_replay in fs/ntfs3/fslog.c in the NTFS journal. This flaw allows a local attacker to crash the system and leads to a kernel information leak problem. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2092542","https://security.netapp.com/advisory/ntap-20230120-0001/","https://bugzilla.redhat.com/show_bug.cgi?id=2092542","https://security.netapp.com/advisory/ntap-20230120-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49001 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: riscv: fix race when vmap stack overflow Currently, when detecting vmap stack overflow, riscv firstly switches to the so called shadow stack, then use this shadow stack to call the get_overflow_stack() to get the overflow stack. However, there's a race here if two or more harts use the same shadow stack at the same time. To solve this race, we introduce spin_shadow_stack atomic var, which will be swap between its own address and 0 in atomic way, when the var is set, it means the shadow_stack is being used; when the var is cleared, it means the shadow_stack isn't being used. [Palmer: Add AQ to the swap, and also some comments.] | ["https://git.kernel.org/stable/c/7e1864332fbc1b993659eab7974da9fe8bf8c128","https://git.kernel.org/stable/c/879fabc5a95401d9bce357e4b1d24ae4a360a81f","https://git.kernel.org/stable/c/ac00301adb19df54f2eae1efc4bad7447c0156ce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1077 | High | fixed |
|
In the Linux kernel, pick_next_rt_entity() may return a type confused entry, not detected by the BUG_ON condition, as the confused entry will not be NULL, but list_head.The buggy error condition would lead to a type confused entry with the list head,which would then be used as a type confused sched_rt_entity,causing memory corruption. | ["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230511-0002/","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7c4a5b89a0b5a57a64b601775b296abf77a9fe97","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230511-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-51782 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. rose_ioctl in net/rose/af_rose.c has a use-after-free because of a rose_accept race condition. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/810c38a369a0a0ce625b5c12169abce1dd9ccd53","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3389 | High | fixed |
|
A use-after-free vulnerability in the Linux Kernel io_uring subsystem can be exploited to achieve local privilege escalation. Racing a io_uring cancel poll request with a linked timeout can cause a UAF in a hrtimer. We recommend upgrading past commit ef7dfac51d8ed961b742218f526bd589f3900a59 (4716c73b188566865bdd79c3a6709696a224ac04 for 5.10 stable and 0e388fce7aec40992eadee654193cad345d62663 for 5.15 stable). | ["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=4716c73b188566865bdd79c3a6709696a224ac04","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y\u0026id=0e388fce7aec40992eadee654193cad345d62663","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59","https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663","https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04","https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0001/","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=4716c73b188566865bdd79c3a6709696a224ac04","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y\u0026id=0e388fce7aec40992eadee654193cad345d62663","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef7dfac51d8ed961b742218f526bd589f3900a59","https://kernel.dance/0e388fce7aec40992eadee654193cad345d62663","https://kernel.dance/4716c73b188566865bdd79c3a6709696a224ac04","https://kernel.dance/ef7dfac51d8ed961b742218f526bd589f3900a59","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0001/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21919 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix potential memory corruption in child_cfs_rq_on_list child_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq. This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list, making the conversion invalid and potentially leading to memory corruption. Depending on the relative positions of leaf_cfs_rq_list and the task group (tg) pointer within the struct, this can cause a memory fault or access garbage data. The issue arises in list_add_leaf_cfs_rq, where both cfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the same leaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list. This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the main conditional in child_cfs_rq_on_list. This ensures that the container_of operation will convert a correct cfs_rq struct. This check is sufficient because only cfs_rqs on the same CPU are added to the list, so verifying the 'prev' pointer against the current rq's list head is enough. Fixes a potential memory corruption issue that due to current struct layout might not be manifesting as a crash but could lead to unpredictable behavior when the layout changes. | ["https://git.kernel.org/stable/c/000c9ee43928f2ce68a156dd40bab7616256f4dd","https://git.kernel.org/stable/c/3b4035ddbfc8e4521f85569998a7569668cccf51","https://git.kernel.org/stable/c/5cb300dcdd27e6a351ac02541e0231261c775852","https://git.kernel.org/stable/c/9cc7f0018609f75a349e42e3aebc3b0e905ba775","https://git.kernel.org/stable/c/b5741e4b9ef3567613b2351384f91d3f16e59986","https://git.kernel.org/stable/c/e1dd09df30ba86716cb2ffab97dc35195c01eb8f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53174 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: make sure cache entry active before cache_show The function `c_show` was called with protection from RCU. This only ensures that `cp` will not be freed. Therefore, the reference count for `cp` can drop to zero, which will trigger a refcount use-after-free warning when `cache_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `cp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 822 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 Call Trace: <TASK> c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/02999e135b013d85c6df738746e8e24699befee4","https://git.kernel.org/stable/c/068c0b50f3f700b94f78850834cd91ae3b34c2c1","https://git.kernel.org/stable/c/2862eee078a4d2d1f584e7f24fa50dddfa5f3471","https://git.kernel.org/stable/c/acfaf37888e0f0732fb6a50ff093dce6d99994d0","https://git.kernel.org/stable/c/c7dac3af57e38b2054f990e573256d90bf887958","https://git.kernel.org/stable/c/d882e2b7fad3f5e5fac66184a347f408813f654a","https://git.kernel.org/stable/c/e9be26735d055c42543a4d047a769cc6d0fb1504","https://git.kernel.org/stable/c/ec305f303bf070b4f6896b7a76009f702956d402"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56558 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: make sure exp active before svc_export_show The function `e_show` was called with protection from RCU. This only ensures that `exp` will not be freed. Therefore, the reference count for `exp` can drop to zero, which will trigger a refcount use-after-free warning when `exp_get` is called. To resolve this issue, use `cache_get_rcu` to ensure that `exp` remains active. ------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 819 at lib/refcount.c:25 refcount_warn_saturate+0xb1/0x120 CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 RIP: 0010:refcount_warn_saturate+0xb1/0x120 ... Call Trace: <TASK> e_show+0x20b/0x230 [nfsd] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/1cecfdbc6bfc89c516d286884c7f29267b95de2b","https://git.kernel.org/stable/c/6cefcadd34e3c71c81ea64b899a0daa86314a51a","https://git.kernel.org/stable/c/7365d1f8de63cffdbbaa2287ce0205438e1a922f","https://git.kernel.org/stable/c/7d8f7816bebcd2e7400bb4d786eccb8f33c9f9ec","https://git.kernel.org/stable/c/7fd29d284b55c2274f7a748e6c5f25b4758b8da5","https://git.kernel.org/stable/c/be8f982c369c965faffa198b46060f8853e0f1f0","https://git.kernel.org/stable/c/e2fa0d0e327279a8defb87b263cd0bf288fd9261"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56678 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm/fault: Fix kfence page fault reporting copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults. Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault(). This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M Some example false negatives: =============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec | ["https://git.kernel.org/stable/c/06dbbb4d5f7126b6307ab807cbf04ecfc459b933","https://git.kernel.org/stable/c/15f78d2c3d1452645bd8b9da909b0ca266f83c43","https://git.kernel.org/stable/c/4d2655754e94741b159aa807b72ea85518a65fd5","https://git.kernel.org/stable/c/7eaeb7a49b6d16640f9f3c9074c05175d74c710b","https://git.kernel.org/stable/c/9ea8d8bf9b625e8ad3be6b0432aecdc549914121","https://git.kernel.org/stable/c/e0a470b5733c1fe068d5c58b0bb91ad539604bc6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4378 | High | N/A | A stack overflow flaw was found in the Linux kernel's SYSCTL subsystem in how a user changes certain kernel parameters and variables. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2152548","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch","https://seclists.org/oss-sec/2022/q4/178","http://packetstormsecurity.com/files/171289/Kernel-Live-Patch-Security-Notice-LNS-0092-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2152548","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-avoid-integer-type-confusion-in-get_proc_long.patch","https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/proc-proc_skip_spaces-shouldn-t-think-it-is-working-on-c-strings.patch","https://seclists.org/oss-sec/2022/q4/178"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53168 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0 CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace: <IRQ> dump_stack_lvl+0x68/0xa0 print_address_description.constprop.0+0x2c/0x3d0 print_report+0xb4/0x270 kasan_report+0xbd/0xf0 tcp_write_timer_handler+0x156/0x3e0 tcp_write_timer+0x66/0x170 call_timer_fn+0xfb/0x1d0 __run_timers+0x3f8/0x480 run_timer_softirq+0x9b/0x100 handle_softirqs+0x153/0x390 __irq_exit_rcu+0x103/0x120 irq_exit_rcu+0xe/0x20 sysvec_apic_timer_interrupt+0x76/0x90 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0 default_idle_call+0x6b/0xa0 cpuidle_idle_call+0x1af/0x1f0 do_idle+0xbc/0x130 cpu_startup_entry+0x33/0x40 rest_init+0x11f/0x210 start_kernel+0x39a/0x420 x86_64_start_reservations+0x18/0x30 x86_64_start_kernel+0x97/0xa0 common_startup_64+0x13e/0x141 </TASK> Allocated by task 595: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x87/0x90 kmem_cache_alloc_noprof+0x12b/0x3f0 copy_net_ns+0x94/0x380 create_new_namespaces+0x24c/0x500 unshare_nsproxy_namespaces+0x75/0xf0 ksys_unshare+0x24e/0x4f0 __x64_sys_unshare+0x1f/0x30 do_syscall_64+0x70/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 100: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x54/0x70 kmem_cache_free+0x156/0x5d0 cleanup_net+0x5d3/0x670 process_one_work+0x776/0xa90 worker_thread+0x2e2/0x560 kthread+0x1a8/0x1f0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 Reproduction script: mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1 ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ --tcp-flags FIN FIN -j DROP (note: In my environment, a DESTROY_CLIENTID operation is always sent immediately, breaking the nfs tcp connection.) ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1 ip netns del netns_1 The reason here is that the tcp socket in netns_1 (nfs side) has been shutdown and closed (done in xs_destroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns_1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems. To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport. | ["https://git.kernel.org/stable/c/0ca87e5063757132a044d35baba40a7d4bb25394","https://git.kernel.org/stable/c/3f23f96528e8fcf8619895c4c916c52653892ec1","https://git.kernel.org/stable/c/61c0a5eac96836de5e3a5897eccdc63162a94936","https://git.kernel.org/stable/c/694ccb05b79ee5f5a9f14c2f80d2635d3bb8bdc3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53177 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: smb: prevent use-after-free due to open_cached_dir error paths If open_cached_dir() encounters an error parsing the lease from the server, the error handling may race with receiving a lease break, resulting in open_cached_dir() freeing the cfid while the queued work is pending. Update open_cached_dir() to drop refs rather than directly freeing the cfid. Have cached_dir_lease_break(), cfids_laundromat_worker(), and invalidate_all_cached_dirs() clear has_lease immediately while still holding cfids->cfid_list_lock, and then use this to also simplify the reference counting in cfids_laundromat_worker() and invalidate_all_cached_dirs(). Fixes this KASAN splat (which manually injects an error and lease break in open_cached_dir()): ================================================================== BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0 Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65 CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Workqueue: cifsiod smb2_cached_lease_break Call Trace: <TASK> dump_stack_lvl+0x77/0xb0 print_report+0xce/0x660 kasan_report+0xd3/0x110 smb2_cached_lease_break+0x27/0xb0 process_one_work+0x50a/0xc50 worker_thread+0x2ba/0x530 kthread+0x17c/0x1c0 ret_from_fork+0x34/0x60 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 open_cached_dir+0xa7d/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2464: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x51/0x70 kfree+0x174/0x520 open_cached_dir+0x97f/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x33/0x60 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x32/0x100 __queue_work+0x5c9/0x870 queue_work_on+0x82/0x90 open_cached_dir+0x1369/0x1fb0 smb2_query_path_info+0x43c/0x6e0 cifs_get_fattr+0x346/0xf10 cifs_get_inode_info+0x157/0x210 cifs_revalidate_dentry_attr+0x2d1/0x460 cifs_getattr+0x173/0x470 vfs_statx_path+0x10f/0x160 vfs_statx+0xe9/0x150 vfs_fstatat+0x5e/0xc0 __do_sys_newfstatat+0x91/0xf0 do_syscall_64+0x95/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff88811cc24c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 16 bytes inside of freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000) | ["https://git.kernel.org/stable/c/47655a12c6b1bca8fa230085eab2e85a076932b7","https://git.kernel.org/stable/c/791f833053578b9fd24252ebb7162a61bc3f805b","https://git.kernel.org/stable/c/97e2afcac0bebfef6a5360f4267ce4c44507b845","https://git.kernel.org/stable/c/a9685b409a03b73d2980bbfa53eb47555802d0a9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53216 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: release svc_expkey/svc_export with rcu_work The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues: 1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e 2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1 Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period. | ["https://git.kernel.org/stable/c/2e4854599200f4d021df8ae17e69221d7c149f3e","https://git.kernel.org/stable/c/ad4363a24a5746b257c0beb5d8cc68f9b62c173f","https://git.kernel.org/stable/c/bd8524148dd8c123334b066faa90590ba2ef8e6f","https://git.kernel.org/stable/c/f8c989a0c89a75d30f899a7cabdc14d72522bb8d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53218 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix race in concurrent f2fs_stop_gc_thread In my test case, concurrent calls to f2fs shutdown report the following stack trace: Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: <TASK> ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7e The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths: [CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAF The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions. Fix it by converting to write lock of s_umount in f2fs_do_shutdown(). | ["https://git.kernel.org/stable/c/60457ed6c67625c87861f96912b4179dc2293896","https://git.kernel.org/stable/c/794fa8792d4eacac191f1cbcc2e81b7369e4662a","https://git.kernel.org/stable/c/7b0033dbc48340a1c1c3f12448ba17d6587ca092","https://git.kernel.org/stable/c/c631207897a9b3d41167ceca58e07f8f94720e42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21927 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu() nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest. Fix this by rejecting packets with an unexpected header length. | ["https://git.kernel.org/stable/c/22b06c89aa6b2d1ecb8aea72edfb9d53af8d5126","https://git.kernel.org/stable/c/9fbc953d6b38bc824392e01850f0aeee3b348722","https://git.kernel.org/stable/c/ad95bab0cd28ed77c2c0d0b6e76e03e031391064"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4623 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation. If a class with a link-sharing curve (i.e. with the HFSC_FSC flag set) has a parent without a link-sharing curve, then init_vf() will call vttree_insert() on the parent, but vttree_remove() will be skipped in update_vf(). This leaves a dangling pointer that can cause a use-after-free. We recommend upgrading past commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f. | ["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://kernel.dance/b3d26c5702c7d6c45456326e56d2ccf3f103e60f","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4015 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation. On an error when building a nftables rule, deactivating immediate expressions in nft_immediate_deactivate() can lead unbinding the chain and objects be deactivated but later used. We recommend upgrading past commit 0a771f7b266b02d262900c75f1e175c7fe76fec2. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2","https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a771f7b266b02d262900c75f1e175c7fe76fec2","https://kernel.dance/0a771f7b266b02d262900c75f1e175c7fe76fec2","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-24958 | High | fixed |
|
drivers/usb/gadget/legacy/inode.c in the Linux kernel through 5.16.8 mishandles dev->buf release. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://github.com/torvalds/linux/commit/501e38a5531efbd77d5c73c0ba838a889bfc1d74","https://github.com/torvalds/linux/commit/89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SUVZA2YVOQJBJTDIDQ5HF5TAU2C6WP6H/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20220225-0008/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://github.com/torvalds/linux/commit/501e38a5531efbd77d5c73c0ba838a889bfc1d74","https://github.com/torvalds/linux/commit/89f3594d0de58e8a57d92d497dea9fee3d4b9cda","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/SUVZA2YVOQJBJTDIDQ5HF5TAU2C6WP6H/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TCW2KZYJ2H6BKZE3CVLHRIXYDGNYYC5P/","https://security.netapp.com/advisory/ntap-20220225-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46728 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check index for aux_rd_interval before using aux_rd_interval has size of 7 and should be checked. This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity. | ["https://git.kernel.org/stable/c/48e0b68e2360b16edf2a0bae05c0051c00fbb48a","https://git.kernel.org/stable/c/6c588e9350dd7a9fb97a56fe74852c9ecc44450c","https://git.kernel.org/stable/c/9ba2ea6337b4f159aecb177555a6a81da92d302e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46749 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush() This adds a check before freeing the rx->skb in flush and close functions to handle the kernel crash seen while removing driver after FW download fails or before FW download completes. dmesg log: [ 54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080 [ 54.643398] Mem abort info: [ 54.646204] ESR = 0x0000000096000004 [ 54.649964] EC = 0x25: DABT (current EL), IL = 32 bits [ 54.655286] SET = 0, FnV = 0 [ 54.658348] EA = 0, S1PTW = 0 [ 54.661498] FSC = 0x04: level 0 translation fault [ 54.666391] Data abort info: [ 54.669273] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 54.674768] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 54.674771] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000 [ 54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000 [ 54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse [ 54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2 [ 54.744364] Hardware name: FSL i.MX8MM EVK board (DT) [ 54.744368] Workqueue: hci0 hci_power_on [ 54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 54.757249] pc : kfree_skb_reason+0x18/0xb0 [ 54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.782921] sp : ffff8000805ebca0 [ 54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000 [ 54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230 [ 54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92 [ 54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff [ 54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857 [ 54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642 [ 54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688 [ 54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000 [ 54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac [ 54.857599] Call trace: [ 54.857601] kfree_skb_reason+0x18/0xb0 [ 54.863878] btnxpuart_flush+0x40/0x58 [btnxpuart] [ 54.863888] hci_dev_open_sync+0x3a8/0xa04 [ 54.872773] hci_power_on+0x54/0x2e4 [ 54.881832] process_one_work+0x138/0x260 [ 54.881842] worker_thread+0x32c/0x438 [ 54.881847] kthread+0x118/0x11c [ 54.881853] ret_from_fork+0x10/0x20 [ 54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400) [ 54.896410] ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/013dae4735d2010544d1f2121bdeb8e6c9ea171e","https://git.kernel.org/stable/c/056e0cd381d59a9124b7c43dd715e15f56a11635","https://git.kernel.org/stable/c/c68bbf5e334b35b36ac5b9f0419f1f93f796bad1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46760 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: usb: schedule rx work after everything is set up Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup. The stack trace looks like this: rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on. Fix this by moving the first usb_submit_urb after everything is set up. For me, this bug manifested as: [ 8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [ 8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status. | ["https://git.kernel.org/stable/c/25eaef533bf3ccc6fee5067aac16f41f280e343e","https://git.kernel.org/stable/c/adc539784c98a7cc602cbf557debfc2e7b9be8b3","https://git.kernel.org/stable/c/c83d464b82a8ad62ec9077637f75d73fe955635a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46762 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Fix possible access to a freed kirqfd instance Nothing prevents simultaneous ioctl calls to privcmd_irqfd_assign() and privcmd_irqfd_deassign(). If that happens, it is possible that a kirqfd created and added to the irqfds_list by privcmd_irqfd_assign() may get removed by another thread executing privcmd_irqfd_deassign(), while the former is still using it after dropping the locks. This can lead to a situation where an already freed kirqfd instance may be accessed and cause kernel oops. Use SRCU locking to prevent the same, as is done for the KVM implementation for irqfds. | ["https://git.kernel.org/stable/c/112fd2f02b308564724b8e81006c254d20945c4b","https://git.kernel.org/stable/c/611ff1b1ae989a7bcce3e2a8e132ee30e968c557","https://git.kernel.org/stable/c/e997b357b13a7d95de31681fc54fcc34235fa527"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46776 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Run DC_LOG_DC after checking link->link_enc [WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before. This fixes 1 REVERSE_INULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/3a82f62b0d9d7687eac47603bb6cd14a50fa718b","https://git.kernel.org/stable/c/874e3bb302f97b94ac548959ec4f925b8e7b45e2","https://git.kernel.org/stable/c/adc74d25cdbba978afbb57caec23bbcd0329f7b8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46806 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix the warning division or modulo by zero Checks the partition mode and returns an error for an invalid mode. | ["https://git.kernel.org/stable/c/1a00f2ac82d6bc6689388c7edcd2a4bd82664f3c","https://git.kernel.org/stable/c/a01618adcba78c6bd6c4557a4a5e32f58b658cd1","https://git.kernel.org/stable/c/d116bb921e8b104f45d1f30a473ea99ef4262b9a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46843 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Remove SCSI host only if added If host tries to remove ufshcd driver from a UFS device it would cause a kernel panic if ufshcd_async_scan fails during ufshcd_probe_hba before adding a SCSI host with scsi_add_host and MCQ is enabled since SCSI host has been defered after MCQ configuration introduced by commit 0cab4023ec7b ("scsi: ufs: core: Defer adding host to SCSI if MCQ is supported"). To guarantee that SCSI host is removed only if it has been added, set the scsi_host_added flag to true after adding a SCSI host and check whether it is set or not before removing it. | ["https://git.kernel.org/stable/c/2f49e05d6b58d660f035a75ff96b77071b4bd5ed","https://git.kernel.org/stable/c/3844586e9bd9845140e1078f1e61896b576ac536","https://git.kernel.org/stable/c/7cbff570dbe8907e23bba06f6414899a0fbb2fcc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46860 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here. | ["https://git.kernel.org/stable/c/479ffee68d59c599f8aed8fa2dcc8e13e7bd13c3","https://git.kernel.org/stable/c/4bfee9346d8c17d928ef6da2b8bffab88fa2a553","https://git.kernel.org/stable/c/8d92bafd4c67efb692f722d73a07412b5f88c6d6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usbnet: ipheth: do not stop RX on failing RX callback RX callbacks can fail for multiple reasons: * Payload too short * Payload formatted incorrecly (e.g. bad NCM framing) * Lack of memory None of these should cause the driver to seize up. Make such failures non-critical and continue processing further incoming URBs. | ["https://git.kernel.org/stable/c/08ca800b0cd56d5e26722f68b18bbbf6840bf44b","https://git.kernel.org/stable/c/4d1cfa3afb8627435744ecdc6d8b58bc72ee0f4c","https://git.kernel.org/stable/c/74efed51e0a4d62f998f806c307778b47fc73395"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53094 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30 | ["https://git.kernel.org/stable/c/3406bfc813a9bbd9c3055795e985f527b7852e8c","https://git.kernel.org/stable/c/4e1e3dd88a4cedd5ccc1a3fc3d71e03b70a7a791","https://git.kernel.org/stable/c/bb5738957d92c8603a90c9664d34236641c221b2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52485 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before sending a command [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we're done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. | ["https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009","https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39","https://git.kernel.org/stable/c/303197775a97416b62d4da69280d0c120a20e009","https://git.kernel.org/stable/c/8892780834ae294bc3697c7d0e056d7743900b39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21634 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cgroup/cpuset: remove kernfs active break A warning was found: WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS: 00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kernfs_drain+0x15e/0x2f0 __kernfs_remove+0x165/0x300 kernfs_remove_by_name_ns+0x7b/0xc0 cgroup_rm_file+0x154/0x1c0 cgroup_addrm_files+0x1c2/0x1f0 css_clear_dir+0x77/0x110 kill_css+0x4c/0x1b0 cgroup_destroy_locked+0x194/0x380 cgroup_rmdir+0x2a/0x140 It can be explained by: rmdir echo 1 > cpuset.cpus kernfs_fop_write_iter // active=0 cgroup_rm_file kernfs_remove_by_name_ns kernfs_get_active // active=1 __kernfs_remove // active=0x80000002 kernfs_drain cpuset_write_resmask wait_event //waiting (active == 0x80000001) kernfs_break_active_protection // active = 0x80000001 // continue kernfs_unbreak_active_protection // active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs kernfs_put_active This warning is caused by 'kernfs_break_active_protection' when it is writing to cpuset.cpus, and the cgroup is removed concurrently. The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change involves calling flush_work(), which can create a multiple processes circular locking dependency that involve cgroup_mutex, potentially leading to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break kernfs active protection in cpuset_write_resmask()") added 'kernfs_break_active_protection' in the cpuset_write_resmask. This could lead to this warning. After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset_write_resmask no longer needs to wait the hotplug to finish, which means that concurrent hotplug and cpuset operations are no longer possible. Therefore, the deadlock doesn't exist anymore and it does not have to 'break active protection' now. To fix this warning, just remove kernfs_break_active_protection operation in the 'cpuset_write_resmask'. | ["https://git.kernel.org/stable/c/11cb1d643a74665a4e14749414f48f82cbc15c64","https://git.kernel.org/stable/c/3cb97a927fffe443e1e7e8eddbfebfdb062e86ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47678 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation. | ["https://git.kernel.org/stable/c/483397b4ba280813e4a9c161a0a85172ddb43d19","https://git.kernel.org/stable/c/662ec52260cc07b9ae53ecd3925183c29d34288b","https://git.kernel.org/stable/c/8c2bd38b95f75f3d2a08c93e35303e26d480d24e","https://git.kernel.org/stable/c/997ba8889611891f91e8ad83583466aeab6239a3","https://git.kernel.org/stable/c/a7722921adb046e3836eb84372241f32584bdb07"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4134 | Medium | fixed |
|
A use-after-free vulnerability was found in the cyttsp4_core driver in the Linux kernel. This issue occurs in the device cleanup routine due to a possible rearming of the watchdog_timer from the workqueue. This could allow a local user to crash the system, causing a denial of service. | ["https://access.redhat.com/security/cve/CVE-2023-4134","https://bugzilla.redhat.com/show_bug.cgi?id=2221700"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47658 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. | ["https://git.kernel.org/stable/c/56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce","https://git.kernel.org/stable/c/5d734665cd5d93270731e0ff1dd673fec677f447","https://git.kernel.org/stable/c/d93a2f86b0a998aa1f0870c85a2a60a0771ef89a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47664 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned. | ["https://git.kernel.org/stable/c/16ccaf581da4fcf1e4d66086cf37263f9a656d43","https://git.kernel.org/stable/c/5127c42c77de18651aa9e8e0a3ced190103b449c","https://git.kernel.org/stable/c/ee73a15d4a8ce8fb02d7866f7cf78fcdd16f0fcc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47666 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Set phy->enable_completion only when we wait for it pm8001_phy_control() populates the enable_completion pointer with a stack address, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, and returns. The problem arises when a phy control response comes late. After 300 ms the pm8001_phy_control() function returns and the passed enable_completion stack address is no longer valid. Late phy control response invokes complete() on a dangling enable_completion pointer which leads to a kernel crash. | ["https://git.kernel.org/stable/c/7b1d779647afaea9185fa2f150b1721e7c1aae89","https://git.kernel.org/stable/c/e4f949ef1516c0d74745ee54a0f4882c1f6c7aea","https://git.kernel.org/stable/c/f14d3e1aa613311c744af32d75125e95fc8ffb84"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49888 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/ | ["https://git.kernel.org/stable/c/4902a6a0dc593c82055fc8c9ada371bafe26c9cc","https://git.kernel.org/stable/c/7dd34d7b7dcf9309fc6224caf4dd5b35bedddcb7","https://git.kernel.org/stable/c/d22e45a369afc7c28f11acfa5b5e8e478227ca5d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49904 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe() | ["https://git.kernel.org/stable/c/4416377ae1fdc41a90b665943152ccd7ff61d3c5","https://git.kernel.org/stable/c/5ec731ef47f1dba34daad3e51a93de793f9319ac","https://git.kernel.org/stable/c/8e87763946f708063d7e5303339598abbb8c5aac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49918 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681) | ["https://git.kernel.org/stable/c/4f47292f488fa7041284dca1f1244116c18721f1","https://git.kernel.org/stable/c/96d4c2ee18d732a248d053aae8c4a27cb1d68d1c","https://git.kernel.org/stable/c/ac2140449184a26eac99585b7f69814bd3ba8f2d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49922 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity. | ["https://git.kernel.org/stable/c/1ff12bcd7deaeed25efb5120433c6a45dd5504a8","https://git.kernel.org/stable/c/5e9386baa3033c369564d55de4bab62423e8a1d3","https://git.kernel.org/stable/c/65e1d2c291553ef3f433a0b7109cc3002a5f40ae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49990 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/xe/hdcp: Check GSC structure validity Sometimes xe_gsc is not initialized when checked at HDCP capability check. Add gsc structure check to avoid null pointer error. | ["https://git.kernel.org/stable/c/7266a424b1e502745170322e3c27f697d12de627","https://git.kernel.org/stable/c/b4224f6bae3801d589f815672ec62800a1501b0d","https://git.kernel.org/stable/c/c940627857eedca8407b84b40ceb4252b100d291"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50004 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 [WHY & HOW] Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override to match HW spec. (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba) | ["https://git.kernel.org/stable/c/0d5e5e8a0aa49ea2163abf128da3b509a6c58286","https://git.kernel.org/stable/c/4010efc8516899981cc3b57be2d4a2d5d9e50228","https://git.kernel.org/stable/c/945dc25eda88b5d6e30c9686dc619ab981c22d0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22066 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-card: Add NULL check in imx_card_probe() devm_kasprintf() returns NULL when memory allocation fails. Currently, imx_card_probe() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. | ["https://git.kernel.org/stable/c/018e6cf2503e60087747b0ebc190e18b3640766f","https://git.kernel.org/stable/c/38253922a89a742e7e622f626b41c64388367361","https://git.kernel.org/stable/c/4d8458e48ff135bddc402ad79821dc058ea163d0","https://git.kernel.org/stable/c/93d34608fd162f725172e780b1c60cc93a920719","https://git.kernel.org/stable/c/b01700e08be99e3842570142ec5973ccd7e73eaf","https://git.kernel.org/stable/c/dd2bbb9564d0d24a2643ad90008a79840368c4b4","https://git.kernel.org/stable/c/e283a5bf4337a7300ac5e6ae363cc8b242a0b4b7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46678 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bonding: change ipsec_lock from spin lock to mutex In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave. [ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] <TASK> [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53 As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved. | ["https://git.kernel.org/stable/c/2aeeef906d5a526dc60cf4af92eda69836c39b1f","https://git.kernel.org/stable/c/56354b0a2c24a7828eeed7de4b4dc9652d9affa3","https://git.kernel.org/stable/c/6b598069164ac1bb60996d6ff94e7f9169dbd2d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2873 | Medium | fixed |
|
An out-of-bounds memory access flaw was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way a user triggers the I2C_SMBUS_BLOCK_DATA (with the ioctl I2C_SMBUS) with malicious input data. This flaw allows a local user to crash the system. | ["https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2023/dsa-5324","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/lkml/20220729093451.551672-1-zheyuma97%40gmail.com/T/","https://security.netapp.com/advisory/ntap-20230120-0001/","https://www.debian.org/security/2023/dsa-5324"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26841 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Update cpu_sibling_map when disabling nonboot CPUs Update cpu_sibling_map when disabling nonboot CPUs by defining & calling clear_cpu_sibling_map(), otherwise we get such errors on SMT systems: jump label: negative count! WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280 a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001 t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000 t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964 t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8 s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040 s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000 90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0 900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001 0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0 0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f 6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000 900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000 0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4 0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c ... Call Trace: [<9000000000224528>] show_stack+0x48/0x1a0 [<900000000179afc8>] dump_stack_lvl+0x78/0xa0 [<9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4 | ["https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2","https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5","https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e","https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2","https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5","https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56757 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btusb: mediatek: add intf release flow when usb disconnect MediaTek claim an special usb intr interface for ISO data transmission. The interface need to be released before unregistering hci device when usb disconnect. Removing BT usb dongle without properly releasing the interface may cause Kernel panic while unregister hci device. | ["https://git.kernel.org/stable/c/489304e67087abddc2666c5af0159cb95afdcf59","https://git.kernel.org/stable/c/cc569d791ab2a0de74f76e470515d25d24c9b84b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57872 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove() This will ensure that the scsi host is cleaned up properly using scsi_host_dev_release(). Otherwise, it may lead to memory leaks. | ["https://git.kernel.org/stable/c/897df60c16d54ad515a3d0887edab5c63da06d1f","https://git.kernel.org/stable/c/cd188519d2467ab4c2141587b0551ba030abff0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21649 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is sent on HIP08 devices Currently, HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL. But the tx process would still try to set hardware time stamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash. [ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge] [ 128.292938] sp : ffff800059b93140 [ 128.297200] x29: ffff800059b93140 x28: 0000000000003280 [ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080 [ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001 [ 128.315969] x23: 0000000000000000 x22: 0000000000000194 [ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000 [ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000 [ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24 [ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000 [ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368 [ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02 [ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0 [ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000 [ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff [ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294 [ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080 [ 128.390626] Call trace: [ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge] [ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3] [ 128.405468] xmit_one.constprop.0+0xc4/0x200 [ 128.410600] dev_hard_start_xmit+0x54/0xf0 [ 128.415556] sch_direct_xmit+0xe8/0x634 [ 128.420246] __dev_queue_xmit+0x224/0xc70 [ 128.425101] dev_queue_xmit+0x1c/0x40 [ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch] [ 128.435409] do_output+0x60/0x17c [openvswitch] [ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch] [ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch] [ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch] [ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch] [ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch] [ 128.471460] xmit_one.constprop.0+0xc4/0x200 [ 128.476561] dev_hard_start_xmit+0x54/0xf0 [ 128.481489] __dev_queue_xmit+0x968/0xc70 [ 128.486330] dev_queue_xmit+0x1c/0x40 [ 128.490856] ip_finish_output2+0x250/0x570 [ 128.495810] __ip_finish_output+0x170/0x1e0 [ 128.500832] ip_finish_output+0x3c/0xf0 [ 128.505504] ip_output+0xbc/0x160 [ 128.509654] ip_send_skb+0x58/0xd4 [ 128.513892] udp_send_skb+0x12c/0x354 [ 128.518387] udp_sendmsg+0x7a8/0x9c0 [ 128.522793] inet_sendmsg+0x4c/0x8c [ 128.527116] __sock_sendmsg+0x48/0x80 [ 128.531609] __sys_sendto+0x124/0x164 [ 128.536099] __arm64_sys_sendto+0x30/0x5c [ 128.540935] invoke_syscall+0x50/0x130 [ 128.545508] el0_svc_common.constprop.0+0x10c/0x124 [ 128.551205] do_el0_svc+0x34/0xdc [ 128.555347] el0_svc+0x20/0x30 [ 128.559227] el0_sync_handler+0xb8/0xc0 [ 128.563883] el0_sync+0x160/0x180 | ["https://git.kernel.org/stable/c/9741e72b2286de8b38de9db685588ac421a95c87","https://git.kernel.org/stable/c/f19ab3ef96d9626e5f1bdc56d3574c355e83d623"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21682 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: always recalculate features after XDP clearing, fix null-deref Recalculate features when XDP is detached. Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on] After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on The fact that HW-GRO doesn't get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdev_update_features(). The driver doesn't handle reconfiguring two things at a time very robustly. Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") we only reconfigure the RSS hash table if the "effective" number of Rx rings has changed. If HW-GRO is enabled "effective" number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement "pending" after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings && condition in __bnxt_reserve_rings() will be false. The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0 As we try to access a freed ring. The issue is present since XDP support was added, really, but prior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in __bnxt_reserve_rings()") it wasn't causing major issues. | ["https://git.kernel.org/stable/c/08831a894d18abfaabb5bbde7c2069a7fb41dd93","https://git.kernel.org/stable/c/f0aa6a37a3dbb40b272df5fc6db93c114688adcd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42253 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: pca953x: fix pca953x_irq_bus_sync_unlock race Ensure that `i2c_lock' is held when setting interrupt latch and mask in pca953x_irq_bus_sync_unlock() in order to avoid races. The other (non-probe) call site pca953x_gpio_set_multiple() ensures the lock is held before calling pca953x_write_regs(). The problem occurred when a request raced against irq_bus_sync_unlock() approximately once per thousand reboots on an i.MX8MP based system. * Normal case 0-0022: write register AI|3a {03,02,00,00,01} Input latch P0 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 * Race case 0-0022: write register AI|08 {ff,00,00,00,00} Output P3 0-0022: write register AI|08 {03,02,00,00,01} *** Wrong register *** 0-0022: write register AI|12 {fc,00,00,00,00} Config P3 0-0022: write register AI|49 {fc,fd,ff,ff,fe} Interrupt mask P0 | ["https://git.kernel.org/stable/c/58a5c93bd1a6e949267400080f07e57ffe05ec34","https://git.kernel.org/stable/c/bfc6444b57dc7186b6acc964705d7516cbaf3904","https://git.kernel.org/stable/c/de7cffa53149c7b48bd1bb29b02390c9f05b7f41","https://git.kernel.org/stable/c/e2ecdddca80dd845df42376e4b0197fe97018ba2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56623 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix use after free on unload System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpc_thread to terminate (UNLOADING flag and kthread_stop). On setting the UNLOADING flag when dpc_thread happens to run at the time and sees the flag, this causes dpc_thread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free. Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop as the main signal to exit dpc_thread. [596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:__slab_free+0x17d/0x360 ... [596663.813008] Call Trace: [596663.813022] ? __dentry_kill+0x121/0x170 [596663.813030] ? _cond_resched+0x15/0x30 [596663.813034] ? _cond_resched+0x15/0x30 [596663.813039] ? wait_for_completion+0x35/0x190 [596663.813048] ? try_to_wake_up+0x63/0x540 [596663.813055] free_task+0x5a/0x60 [596663.813061] kthread_stop+0xf3/0x100 [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx] | ["https://git.kernel.org/stable/c/07c903db0a2ff84b68efa1a74a4de353ea591eb0","https://git.kernel.org/stable/c/12f04fc8580eafb0510f805749553eb6213f323e","https://git.kernel.org/stable/c/15369e774f27ec790f207de87c0b541e3f90b22d","https://git.kernel.org/stable/c/6abf16d3c915b2feb68c1c8b25fcb71b13f98478","https://git.kernel.org/stable/c/b3e6f25176f248762a24d25ab8cf8c5e90874f80","https://git.kernel.org/stable/c/ca36d9d53745d5ec8946ef85006d4da605ea7c54"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52511 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue. | ["https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18","https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355","https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb","https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc","https://git.kernel.org/stable/c/171f8a49f212e87a8b04087568e1b3d132e36a18","https://git.kernel.org/stable/c/b3c21c9c7289692f4019f163c3b06d8bdf78b355","https://git.kernel.org/stable/c/e15bb292b24630ee832bfc7fd616bd72c7682bbb","https://git.kernel.org/stable/c/ff05ed4ae214011464a0156f05cac1b0b46b5fbc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3619 | Medium | N/A | A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c of the component Bluetooth. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. VDB-211918 is the identifier assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=97097c85c088e11651146da32a4e1cdb9dfa6193","https://vuldb.com/?id.211918","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=97097c85c088e11651146da32a4e1cdb9dfa6193","https://vuldb.com/?id.211918"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1192 | Medium | fixed |
|
A use-after-free flaw was found in smb2_is_status_io_timeout() in CIFS in the Linux Kernel. After CIFS transfers response data to a system call, there are still local variable points to the memory region, and if the system call frees it faster than CIFS uses it, CIFS will access a free memory region, leading to a denial of service. | ["https://access.redhat.com/security/cve/CVE-2023-1192","https://bugzilla.redhat.com/show_bug.cgi?id=2154178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f","https://access.redhat.com/security/cve/CVE-2023-1192","https://bugzilla.redhat.com/show_bug.cgi?id=2154178","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d527f51331cace562393a8038d870b3e9916686f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42158 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle: WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770) | ["https://git.kernel.org/stable/c/22e6824622e8a8889df0f8fc4ed5aea0e702a694","https://git.kernel.org/stable/c/62151a0acde90823bdfa991d598c85cf4b1d387d","https://git.kernel.org/stable/c/22e6824622e8a8889df0f8fc4ed5aea0e702a694","https://git.kernel.org/stable/c/62151a0acde90823bdfa991d598c85cf4b1d387d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1652 | High | fixed |
|
A use-after-free flaw was found in nfsd4_ssc_setup_dul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem. | ["https://access.redhat.com/security/cve/cve-2023-1652","https://security.netapp.com/advisory/ntap-20230511-0006/","https://access.redhat.com/security/cve/cve-2023-1652","https://security.netapp.com/advisory/ntap-20230511-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52479 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. | ["https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd","https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930","https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce","https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9","https://git.kernel.org/stable/c/694e13732e830cbbfedb562e57f28644927c33fd","https://git.kernel.org/stable/c/8226ffc759ea59f10067b9acdf7f94bae1c69930","https://git.kernel.org/stable/c/c69813471a1ec081a0b9bf0c6bd7e8afd818afce","https://git.kernel.org/stable/c/d5b0e9d3563e7e314a850e81f42b2ef6f39882f9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1380 | High | fixed |
|
A slab-out-of-bound read problem was found in brcmf_get_assoc_ies in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c in the Linux Kernel. This issue could occur when assoc_info->req_len data is bigger than the size of the buffer, defined as WL_EXTRA_BUF_MAX, leading to a denial of service. | ["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177883","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u","https://security.netapp.com/advisory/ntap-20230511-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/03/14/1","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177883","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-wireless/20230309104457.22628-1-jisoo.jang%40yonsei.ac.kr/T/#u","https://security.netapp.com/advisory/ntap-20230511-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/03/14/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26962 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang: 1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set; After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang: [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 This is because reshape can't make progress. For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more: 1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'. However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO. | ["https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677","https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1","https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304","https://git.kernel.org/stable/c/41425f96d7aa59bc865f60f5dda3d7697b555677","https://git.kernel.org/stable/c/5943a34bf6bab5801e08a55f63e1b8d5bc90dae1","https://git.kernel.org/stable/c/a8d249d770cb357d16a2097b548d2e4c1c137304"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-40969 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: don't set RO when shutting down f2fs Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread); | ["https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a","https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7","https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563","https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a","https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7","https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56715 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ionic: Fix netdev notifier unregister on failure If register_netdev() fails, then the driver leaks the netdev notifier. Fix this by calling ionic_lif_unregister() on register_netdev() failure. This will also call ionic_lif_unregister_phc() if it has already been registered. | ["https://git.kernel.org/stable/c/87847938f5708b2509b279369c96572254bcf2ba","https://git.kernel.org/stable/c/9590d32e090ea2751e131ae5273859ca22f5ac14","https://git.kernel.org/stable/c/da5736f516a664a9e1ff74902663c64c423045d2","https://git.kernel.org/stable/c/da93a12876f8b969df7316dc93aac7e725f88252","https://git.kernel.org/stable/c/ee2e931b2b46de9af7f681258e8ec8e2cd81cfc6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50187 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. | ["https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22","https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967","https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0","https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53121 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated--- | ["https://git.kernel.org/stable/c/094d1a2121cee1e85ab07d74388f94809dcfb5b9","https://git.kernel.org/stable/c/0d568258f99f2076ab02e9234cbabbd43e12f30e","https://git.kernel.org/stable/c/5b47c2f47c2fe921681f4a4fe2790375e6c04cdd","https://git.kernel.org/stable/c/933ef0d17f012b653e9e6006e3f50c8d0238b5ed","https://git.kernel.org/stable/c/9ca314419930f9135727e39d77e66262d5f7bef6","https://git.kernel.org/stable/c/a508c74ceae2f5a4647f67c362126516d6404ed9","https://git.kernel.org/stable/c/bfba288f53192db08c68d4c568db9783fb9cb838"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53122 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf(). | ["https://git.kernel.org/stable/c/0a9a182ea5c7bb0374e527130fd85024ace7279b","https://git.kernel.org/stable/c/24995851d58c4a205ad0ffa7b2f21e479a9c8527","https://git.kernel.org/stable/c/aad6412c63baa39dd813e81f16a14d976b3de2e8","https://git.kernel.org/stable/c/ce7356ae35943cc6494cc692e62d51a734062b7d","https://git.kernel.org/stable/c/ff825ab2f455299c0c7287550915a8878e2a66e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-47929 | Medium | fixed |
|
In the Linux kernel before 6.1.6, a NULL pointer dereference bug in the traffic control subsystem allows an unprivileged user to trigger a denial of service (system crash) via a crafted traffic control configuration that is set up with "tc qdisc" and "tc class" commands. This affects qdisc_graft in net/sched/sch_api.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html","https://www.debian.org/security/2023/dsa-5324","https://www.spinics.net/lists/netdev/msg555705.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.6","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96398560f26aa07e8f2969d73c8197e6a6d10407","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://tldp.org/HOWTO/Traffic-Control-HOWTO/components.html","https://www.debian.org/security/2023/dsa-5324","https://www.spinics.net/lists/netdev/msg555705.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53145 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: um: Fix potential integer overflow during physmem setup This issue happens when the real map size is greater than LONG_MAX, which can be easily triggered on UML/i386. | ["https://git.kernel.org/stable/c/1575df968650d11771359e5ac78278c5b0cc19f3","https://git.kernel.org/stable/c/1bd118c5f887802cef2d9ba0d1917258667f1cae","https://git.kernel.org/stable/c/5c710f45811e7e2bfcf703980c306f19c7e1ecfe","https://git.kernel.org/stable/c/a875c023155ea92b75d6323977003e64d92ae7fc","https://git.kernel.org/stable/c/a98b7761f697e590ed5d610d87fa12be66f23419","https://git.kernel.org/stable/c/a9c95f787b88b29165563fd97761032db77116e7","https://git.kernel.org/stable/c/d1a211e5210d31da8f49fc0021bf7129b726468c","https://git.kernel.org/stable/c/e6102b72edc4eb8c0858df00ba74b5ce579c8fa2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56688 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport Since transport->sock has been set to NULL during reset transport, XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, the xs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request() to dereference the transport->sock that has been set to NULL. | ["https://git.kernel.org/stable/c/3811172e8c98ceebd12fe526ca6cb37a1263c964","https://git.kernel.org/stable/c/4db9ad82a6c823094da27de4825af693a3475d51","https://git.kernel.org/stable/c/638a8fa5a7e641f9401346c57e236f02379a0c40","https://git.kernel.org/stable/c/66d11ca91bf5100ae2e6b5efad97e58d8448843a","https://git.kernel.org/stable/c/86a1f9fa24804cd7f9d7dd3f24af84fc7f8ec02e","https://git.kernel.org/stable/c/87a95ee34a48dfad198a2002e4966e1d63d53f2b","https://git.kernel.org/stable/c/cc91d59d34ff6a6fee1c0b48612081a451e05e9a","https://git.kernel.org/stable/c/fe6cbf0b2ac3cf4e21824a44eaa336564ed5e960"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56698 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix looping of queued SG entries The dwc3_request->num_queued_sgs is decremented on completion. If a partially completed request is handled, then the dwc3_request->num_queued_sgs no longer reflects the total number of num_queued_sgs (it would be cleared). Correctly check the number of request SG entries remained to be prepare and queued. Failure to do this may cause null pointer dereference when accessing non-existent SG entry. | ["https://git.kernel.org/stable/c/0247da93bf62d33304b7bf97850ebf2a86e06d28","https://git.kernel.org/stable/c/1534f6f69393aac773465d80d31801b554352627","https://git.kernel.org/stable/c/70777a23a54e359cfdfafc625a57cd56434f3859","https://git.kernel.org/stable/c/8ceb21d76426bbe7072cc3e43281e70c0d664cc7","https://git.kernel.org/stable/c/b7c3d0b59213ebeedff63d128728ce0b3d7a51ec","https://git.kernel.org/stable/c/b7fc65f5141c24785dc8c19249ca4efcf71b3524","https://git.kernel.org/stable/c/c9e72352a10ae89a430449f7bfeb043e75c255d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56724 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. | ["https://git.kernel.org/stable/c/1b734ad0e33648c3988c6a37c2ac16c2d63eda06","https://git.kernel.org/stable/c/2310f5336f32eac9ada2d59b965d578efe25c4bf","https://git.kernel.org/stable/c/56acf415772ee7e10e448b371f52b249aa2d0f7b","https://git.kernel.org/stable/c/5bc6d0da4a32fe34a9960de577e0b7de3454de0c","https://git.kernel.org/stable/c/9b79d59e6b2b515eb9a22bc469ef7b8f0904fc73","https://git.kernel.org/stable/c/b7c7c400de85d915e0da7c2c363553a801c47349","https://git.kernel.org/stable/c/c472b55cc0bc3df805db6a14f50a084884cf18ee","https://git.kernel.org/stable/c/da498e02c92e6d82df8001438dd583b90c570815"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56726 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c Add error pointer check after calling otx2_mbox_get_rsp(). | ["https://git.kernel.org/stable/c/41f39f4c67253f802809310be6846ff408c3c758","https://git.kernel.org/stable/c/54abcec092616a4d01195355eb5d6036fb8fe363","https://git.kernel.org/stable/c/856ad633e11869729be698df2287ecfe6ec31f27","https://git.kernel.org/stable/c/a374e7e79fbdd7574bd89344447b0d4b91ba9801","https://git.kernel.org/stable/c/ac9183023b6a9c09467516abd8aab04f9a2f9564","https://git.kernel.org/stable/c/c5a6c5af434671aea739a5a41c849819144f02c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56728 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c Add error pointer check after calling otx2_mbox_get_rsp(). | ["https://git.kernel.org/stable/c/05a6ce174c0c724e5914e1e5efd826bab8f382b4","https://git.kernel.org/stable/c/2db2194727b1f49a5096c1c3981adef1b7638733","https://git.kernel.org/stable/c/55c41b97001a09bb490ffa2e667e251d75d15ab1","https://git.kernel.org/stable/c/5ff9de1f2712cbca53da2e37d831eea7ffcb43b6","https://git.kernel.org/stable/c/6cda142cee032b8fe65ee11f78721721c3988feb","https://git.kernel.org/stable/c/c0f64fd73b60aee85f88c270c9d714ead27a7b7a","https://git.kernel.org/stable/c/e26f8eac6bb20b20fdb8f7dc695711ebce4c7c5c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56754 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: caam - Fix the pointer passed to caam_qi_shutdown() The type of the last parameter given to devm_add_action_or_reset() is "struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to "struct device *". Pass the correct parameter to devm_add_action_or_reset() so that the resources are released as expected. | ["https://git.kernel.org/stable/c/1f8e2f597b918ca5827a5c6d00b819d064264d1c","https://git.kernel.org/stable/c/6187727e57aec122c8a99c464c74578c810cbe40","https://git.kernel.org/stable/c/66eddb8dcb61065c53098510165f14b54232bcc2","https://git.kernel.org/stable/c/84a185aea7b83f620699de0ea36907d588d89cf6","https://git.kernel.org/stable/c/ad39df0898d3f469776c19d99229be055cc2dcea","https://git.kernel.org/stable/c/ad980b04f51f7fb503530bd1cb328ba5e75a250e","https://git.kernel.org/stable/c/cc386170b3312fd7b5bc4a69a9f52d7f50814526"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56756 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix freeing of the HMB descriptor table The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. | ["https://git.kernel.org/stable/c/3c2fb1ca8086eb139b2a551358137525ae8e0d7a","https://git.kernel.org/stable/c/452f9ddd12bebc04cef741e8ba3806bf0e1fd015","https://git.kernel.org/stable/c/582d9ed999b004fb1d415ecbfa86d4d8df455269","https://git.kernel.org/stable/c/6d0f599db73b099aa724a12736369c4d4d92849d","https://git.kernel.org/stable/c/869cf50b9c9d1059f5223f79ef68fc0bc6210095","https://git.kernel.org/stable/c/ac22240540e0c5230d8c4138e3778420b712716a","https://git.kernel.org/stable/c/cee3bff51a35cab1c5d842d409a7b11caefe2386","https://git.kernel.org/stable/c/fb96d5cfa97a7363245b3dd523f475b04296d87b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56727 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c Adding error pointer check after calling otx2_mbox_get_rsp(). | ["https://git.kernel.org/stable/c/8c9f8b35dc3d4ad8053a72bc0c5a7843591f6b75","https://git.kernel.org/stable/c/a479b3d7586e6f77f8337bbcac980eaf2d0a4029","https://git.kernel.org/stable/c/bd3110bc102ab6292656b8118be819faa0de8dd0","https://git.kernel.org/stable/c/c4eae7bac880edd88aaed6a8ec2997fa85e259c7","https://git.kernel.org/stable/c/e5e60f17d2462ef5c13db4d1a54eef5778fd2295"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48849 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: bypass tiling flag check in virtual display case (v2) vkms leverages common amdgpu framebuffer creation, and also as it does not support FB modifier, there is no need to check tiling flags when initing framebuffer when virtual display is enabled. This can fix below calltrace: amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu] v2: check adev->enable_virtual_display instead as vkms can be enabled in bare metal as well. | ["https://git.kernel.org/stable/c/cb29021be49858059138f75d6311a7c35a9379b2","https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7","https://git.kernel.org/stable/c/fcd1d79aa943fff4fbaa0cce1d576995a7960699","https://git.kernel.org/stable/c/cb29021be49858059138f75d6311a7c35a9379b2","https://git.kernel.org/stable/c/e2b993302f40c4eb714ecf896dd9e1c5be7d4cd7","https://git.kernel.org/stable/c/fcd1d79aa943fff4fbaa0cce1d576995a7960699"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21690 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: storvsc: Ratelimit warning logs to prevent VM denial of service If there's a persistent error in the hypervisor, the SCSI warning for failed I/O can flood the kernel log and max out CPU utilization, preventing troubleshooting from the VM side. Ratelimit the warning so it doesn't DoS the VM. | ["https://git.kernel.org/stable/c/01d1ebdab9ccb73c952e1666a8a80abd194dbc55","https://git.kernel.org/stable/c/088bde862f8d3d0fc52e40e66a0484a246837087","https://git.kernel.org/stable/c/182a4b7c731e95c08cb47f14b87a272b6ab2b2da","https://git.kernel.org/stable/c/81d4dd05c412ba04f9f6b85b718e6da833be290c","https://git.kernel.org/stable/c/d0f0af1bafef33b3e2aa8c3a4ef44db48df9b0ea","https://git.kernel.org/stable/c/d2138eab8cde61e0e6f62d0713e45202e8457d6d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48985 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix race on per-CQ variable napi work_done After calling napi_complete_done(), the NAPIF_STATE_SCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->work_done. If the other thread (for example, from busy_poll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic. To fix this issue, save the per-CQ work_done variable in a local variable before napi_complete_done(), so it won't be corrupted by a possible concurrent thread after napi_complete_done(). Also, add a flag bit to advertise to the NIC firmware: the NAPI work_done variable race is fixed, so the driver is able to reliably support features like busy_poll. | ["https://git.kernel.org/stable/c/18010ff776fa42340efc428b3ea6d19b3e7c7b21","https://git.kernel.org/stable/c/6740d8572ccd1bca50d8a1ca2bedc333f50ed5f3","https://git.kernel.org/stable/c/fe50a9bbeb1f042e756c5cfa7708112c944368de"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42107 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: Don't process extts if PTP is disabled The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic. Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs. To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready. | ["https://git.kernel.org/stable/c/1c4e524811918600683b1ea87a5e0fc2db64fa9b","https://git.kernel.org/stable/c/996422e3230e41468f652d754fefd1bdbcd4604e","https://git.kernel.org/stable/c/1c4e524811918600683b1ea87a5e0fc2db64fa9b","https://git.kernel.org/stable/c/996422e3230e41468f652d754fefd1bdbcd4604e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47679 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug. | ["https://git.kernel.org/stable/c/0eed942bc65de1f93eca7bda51344290f9c573bb","https://git.kernel.org/stable/c/0f8a5b6d0dafa4f533ac82e98f8b812073a7c9d1","https://git.kernel.org/stable/c/3721a69403291e2514d13a7c3af50a006ea1153b","https://git.kernel.org/stable/c/47a68c75052a660e4c37de41e321582ec9496195","https://git.kernel.org/stable/c/489faddb1ae75b0e1a741fe5ca2542a2b5e794a5","https://git.kernel.org/stable/c/540fb13120c9eab3ef203f90c00c8e69f37449d1","https://git.kernel.org/stable/c/6c857fb12b9137fee574443385d53914356bbe11","https://git.kernel.org/stable/c/6cc13a80a26e6b48f78c725c01b91987d61563ef","https://git.kernel.org/stable/c/88b1afbf0f6b221f6c5bb66cc80cd3b38d696687"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48898 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set. Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption. Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller Changes in v4: -- split into two patches Changes in v5: -- delete empty line between tags Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text Patchwork: https://patchwork.freedesktop.org/patch/516121/ | ["https://git.kernel.org/stable/c/1cba0d150fa102439114a91b3e215909efc9f169","https://git.kernel.org/stable/c/785607e5e6fb52caf141e4580de40405565f04f1","https://git.kernel.org/stable/c/984ad875db804948c86ca9e1c2e784ae8252715a","https://git.kernel.org/stable/c/b7dcbca46db3c77fdb02c2a9d6239e5aa3b06a59"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48921 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix fault in reweight_entity Syzbot found a GPF in reweight_entity. This has been bisected to commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") There is a race between sched_post_fork() and setpriority(PRIO_PGRP) within a thread group that causes a null-ptr-deref in reweight_entity() in CFS. The scenario is that the main process spawns number of new threads, which then call setpriority(PRIO_PGRP, 0, -20), wait, and exit. For each of the new threads the copy_process() gets invoked, which adds the new task_struct and calls sched_post_fork() for it. In the above scenario there is a possibility that setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread in the group that is just being created by copy_process(), and for which the sched_post_fork() has not been executed yet. This will trigger a null pointer dereference in reweight_entity(), as it will try to access the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been set in sched_fork(), which is called much earlier in copy_process(), before the new task is added to the thread_group. Now it is done in the sched_post_fork(), which is called after that. To fix the issue the remove the update_load param from the update_load param() function and call reweight_task() only if the task flag doesn't have the TASK_NEW flag set. | ["https://git.kernel.org/stable/c/13765de8148f71fa795e0a6607de37c49ea5915a","https://git.kernel.org/stable/c/589a954daab5e18399860b6c8ffaeaf79844eb20","https://git.kernel.org/stable/c/8f317cd888059c59e2fa924bf4b0957cfa53f78e","https://git.kernel.org/stable/c/e0bcd6b5779352aed88f2e538a82a39f1a7715bb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56664 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix race between element replace and close() Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. __sock_map_delete() unconditionally unrefs the (wrong) element: // set map[0] = s0 map_update_elem(map, 0, s0) // drop fd of s0 close(s0) sock_map_close() lock_sock(sk) (s0!) sock_map_remove_links(sk) link = sk_psock_link_pop() sock_map_unlink(sk, link) sock_map_delete_from_link // replace map[0] with s1 map_update_elem(map, 0, s1) sock_map_update_elem (s1!) lock_sock(sk) sock_map_update_common psock = sk_psock(sk) spin_lock(&stab->lock) osk = stab->sks[idx] sock_map_add_link(..., &stab->sks[idx]) sock_map_unref(osk, &stab->sks[idx]) psock = sk_psock(osk) sk_psock_put(sk, psock) if (refcount_dec_and_test(&psock)) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) unlock_sock(sk) __sock_map_delete spin_lock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sk_test || sk_test == sk) // sk_test (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sock_map_unref(sk, psk) // unref s1; sks[idx] will dangle psock = sk_psock(sk) sk_psock_put(sk, psock) if (refcount_dec_and_test()) sk_psock_drop(sk, psock) spin_unlock(&stab->lock) release_sock(sk) Then close(map) enqueues bpf_map_free_deferred, which finally calls sock_map_free(). This results in some refcount_t warnings along with a KASAN splat [1]. Fix __sock_map_delete(), do not allow sock_map_unref() on elements that may have been replaced. [1]: BUG: KASAN: slab-use-after-free in sock_map_free+0x10e/0x330 Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063 CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: events_unbound bpf_map_free_deferred Call Trace: <TASK> dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 kasan_check_range+0x10f/0x1e0 sock_map_free+0x10e/0x330 bpf_map_free_deferred+0x173/0x320 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1202: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 unix_create1+0x88/0x8a0 unix_create+0xc5/0x180 __sock_create+0x241/0x650 __sys_socketpair+0x1ce/0x420 __x64_sys_socketpair+0x92/0x100 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 46: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 sk_psock_destroy+0x73e/0xa50 process_one_work+0x846/0x1420 worker_thread+0x5b3/0xf80 kthread+0x29e/0x360 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x1a/0x30 The bu ---truncated--- | ["https://git.kernel.org/stable/c/6deb9e85dc9a2ba4414b91c1b5b00b8415910890","https://git.kernel.org/stable/c/b015f19fedd2e12283a8450dd0aefce49ec57015","https://git.kernel.org/stable/c/b79a0d1e9a374d1b376933a354c4fcd01fce0365","https://git.kernel.org/stable/c/bf2318e288f636a882eea39f7e1015623629f168","https://git.kernel.org/stable/c/ed1fc5d76b81a4d681211333c026202cad4d5649","https://git.kernel.org/stable/c/fdb2cd8957ac51f84c9e742ba866087944bb834b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2959 | High | fixed |
|
A race condition was found in the Linux kernel's watch queue due to a missing lock in pipe_resize_ring(). The specific flaw exists within the handling of pipe buffers. The issue results from the lack of proper locking when performing operations on an object. This flaw allows a local user to crash the system or escalate their privileges on the system. | ["https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a","https://security.netapp.com/advisory/ntap-20230214-0005/","https://www.zerodayinitiative.com/advisories/ZDI-22-1165/","https://github.com/torvalds/linux/commit/189b0ddc245139af81198d1a3637cac74f96e13a","https://security.netapp.com/advisory/ntap-20230214-0005/","https://www.zerodayinitiative.com/advisories/ZDI-22-1165/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-26490 | High | N/A | st21nfca_connectivity_event_received in drivers/nfc/st21nfca/se.c in the Linux kernel through 5.16.12 has EVT_TRANSACTION buffer overflows because of untrusted length parameters. | ["https://github.com/torvalds/linux/commit/4fbcc1a4cb20fe26ad0225679c536c80f1648221","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BG4J46EMFPDD5QHYXDUI3PJCZQ7HQAZR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/C5AUUDGSDLGYU7SZSK4PFAN22NISQZBT/","https://security.netapp.com/advisory/ntap-20220429-0004/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/4fbcc1a4cb20fe26ad0225679c536c80f1648221","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BG4J46EMFPDD5QHYXDUI3PJCZQ7HQAZR/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/C5AUUDGSDLGYU7SZSK4PFAN22NISQZBT/","https://security.netapp.com/advisory/ntap-20220429-0004/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52515 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. | ["https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc","https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a","https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206","https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5","https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb","https://git.kernel.org/stable/c/05a10b316adaac1f322007ca9a0383b410d759cc","https://git.kernel.org/stable/c/26788a5b48d9d5cd3283d777d238631c8cd7495a","https://git.kernel.org/stable/c/2b298f9181582270d5e95774e5a6c7a7fb5b1206","https://git.kernel.org/stable/c/b9bdffb3f9aaeff8379c83f5449c6b42cb71c2b5","https://git.kernel.org/stable/c/e193b7955dfad68035b983a0011f4ef3590c85eb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21756 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vsock: Keep the binding until socket destruction Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect(). Prevents socket unbinding during a transport reassignment, which fixes a use-after-free: 1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2) 2. transport->release() calls vsock_remove_bound() without checking if sk was bound and moved to bound list (refcnt=1) 3. vsock_bind() assumes sk is in unbound list and before __vsock_insert_bound(vsock_bound_sockets()) calls __vsock_remove_bound() which does: list_del_init(&vsk->bound_table); // nop sock_put(&vsk->sk); // refcnt=0 BUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dump_stack_lvl+0x68/0x90 print_report+0x174/0x4f6 kasan_report+0xb9/0x190 __vsock_bind+0x62e/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 __kasan_slab_alloc+0x85/0x90 kmem_cache_alloc_noprof+0x131/0x450 sk_prot_alloc+0x5b/0x220 sk_alloc+0x2c/0x870 __vsock_create.constprop.0+0x2e/0xb60 vsock_create+0xe4/0x420 __sock_create+0x241/0x650 __sys_socket+0xf2/0x1a0 __x64_sys_socket+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 2057: kasan_save_stack+0x1e/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kmem_cache_free+0x1a1/0x590 __sk_destruct+0x388/0x5a0 __vsock_bind+0x5e1/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150 RIP: 0010:refcount_warn_saturate+0xce/0x150 __vsock_bind+0x66d/0x730 vsock_bind+0x97/0xe0 __sys_bind+0x154/0x1f0 __x64_sys_bind+0x6e/0xb0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e refcount_t: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150 RIP: 0010:refcount_warn_saturate+0xee/0x150 vsock_remove_bound+0x187/0x1e0 __vsock_release+0x383/0x4a0 vsock_release+0x90/0x120 __sock_release+0xa3/0x250 sock_close+0x14/0x20 __fput+0x359/0xa80 task_work_run+0x107/0x1d0 do_exit+0x847/0x2560 do_group_exit+0xb8/0x250 __x64_sys_exit_group+0x3a/0x50 x64_sys_call+0xfec/0x14f0 do_syscall_64+0x93/0x1b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/3f43540166128951cc1be7ab1ce6b7f05c670d8b","https://git.kernel.org/stable/c/42b33381e5e1f2b967dc4fb4221ddb9aaf10d197","https://git.kernel.org/stable/c/645ce25aa0e67895b11d89f27bb86c9d444c40f8","https://git.kernel.org/stable/c/b1afd40321f1c243cffbcf40ea7ca41aca87fa5e","https://git.kernel.org/stable/c/e48fcb403c2d0e574c19683f09399ab4cf67809c","https://git.kernel.org/stable/c/e7754d564579a5db9c5c9f74228df5d6dd6f1173","https://git.kernel.org/stable/c/fcdd2242c0231032fc84e1404315c245ae56322a","https://github.com/hoefler02/CVE-2025-21756/blob/main/x.c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-26606 | High | fixed |
|
In the Linux kernel 6.0.8, there is a use-after-free in ntfs_trim_fs in fs/ntfs3/bitmap.c. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa","https://lkml.org/lkml/2023/2/20/860","https://security.netapp.com/advisory/ntap-20230316-0010/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=557d19675a470bb0a98beccec38c5dc3735c20fa","https://lkml.org/lkml/2023/2/20/860","https://security.netapp.com/advisory/ntap-20230316-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53141 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks. | ["https://git.kernel.org/stable/c/15794835378ed56fb9bacc6a5dd3b9f33520604e","https://git.kernel.org/stable/c/2e151b8ca31607d14fddc4ad0f14da0893e1a7c7","https://git.kernel.org/stable/c/35f56c554eb1b56b77b3cf197a6b00922d49033d","https://git.kernel.org/stable/c/3c20b5948f119ae61ee35ad8584d666020c91581","https://git.kernel.org/stable/c/591efa494a1cf649f50a35def649c43ae984cd03","https://git.kernel.org/stable/c/78b0f2028f1043227a8eb0c41944027fc6a04596","https://git.kernel.org/stable/c/7ffef5e5d5eeecd9687204a5ec2d863752aafb7e","https://git.kernel.org/stable/c/856023ef032d824309abd5c747241dffa33aae8c","https://git.kernel.org/stable/c/e67471437ae9083fa73fa67eee1573fec1b7c8cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22056 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tunnel: fix geneve_opt type confusion addition When handling multiple NFTA_TUNNEL_KEY_OPTS_GENEVE attributes, the parsing logic should place every geneve_opt structure one by one compactly. Hence, when deciding the next geneve_opt position, the pointer addition should be in units of char *. However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write. [ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nft_tunnel_obj_init+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dump_stack_lvl+0x44/0x5c [ 6.992801] print_report+0x184/0x4be [ 6.993790] kasan_report+0xc5/0x100 [ 6.994252] kasan_check_range+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nft_tunnel_obj_init+0x977/0xa70 [ 6.995677] nft_obj_init+0x10c/0x1b0 [ 6.995891] nf_tables_newobj+0x585/0x950 [ 6.996922] nfnetlink_rcv_batch+0xdf9/0x1020 [ 6.998997] nfnetlink_rcv+0x1df/0x220 [ 6.999537] netlink_unicast+0x395/0x530 [ 7.000771] netlink_sendmsg+0x3d0/0x6d0 [ 7.001462] __sock_sendmsg+0x99/0xa0 [ 7.001707] ____sys_sendmsg+0x409/0x450 [ 7.002391] ___sys_sendmsg+0xfd/0x170 [ 7.003145] __sys_sendmsg+0xea/0x170 [ 7.004359] do_syscall_64+0x5e/0x90 [ 7.005817] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8 Fix this bug with correct pointer addition and conversion in parse and dump code. | ["https://git.kernel.org/stable/c/0a93a710d6df334b828ea064c6d39fda34f901dc","https://git.kernel.org/stable/c/1b755d8eb1ace3870789d48fbd94f386ad6e30be","https://git.kernel.org/stable/c/28d88ee1e1cc8ac2d79aeb112717b97c5c833d43","https://git.kernel.org/stable/c/31d49eb436f2da61280508d7adf8c9b473b967aa","https://git.kernel.org/stable/c/446d94898c560ed2f61e26ae445858a4c4830762","https://git.kernel.org/stable/c/708e268acb3a446ad2a8a3d2e9bd41cc23660cd6","https://git.kernel.org/stable/c/a263d31c8c92e5919d41af57d9479cfb66323782","https://git.kernel.org/stable/c/ca2adfc03cd6273f0b589fe65afc6f75e0fe116e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-28866 | Medium | N/A | In the Linux kernel through 6.2.8, net/bluetooth/hci_sync.c allows out-of-bounds access because amp_init1[] and amp_init2[] are supposed to have an intentionally invalid element, but do not. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a","https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/","https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=95084403f8c070ccf5d7cbe72352519c1798a40a","https://lore.kernel.org/lkml/20230321015018.1759683-1-iam%40sung-woo.kim/","https://patchwork.kernel.org/project/bluetooth/patch/20230322232543.3079578-1-luiz.dentz%40gmail.com"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52629 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sh: push-switch: Reorder cleanup operations to avoid use-after-free bug The original code puts flush_work() before timer_shutdown_sync() in switch_drv_remove(). Although we use flush_work() to stop the worker, it could be rescheduled in switch_timer(). As a result, a use-after-free bug can occur. The details are shown below: (cpu 0) | (cpu 1) switch_drv_remove() | flush_work() | ... | switch_timer // timer | schedule_work(&psw->work) timer_shutdown_sync() | ... | switch_work_handler // worker kfree(psw) // free | | psw->state = 0 // use This patch puts timer_shutdown_sync() before flush_work() to mitigate the bugs. As a result, the worker and timer will be stopped safely before the deallocate operations. | ["https://git.kernel.org/stable/c/246f80a0b17f8f582b2c0996db02998239057c65","https://git.kernel.org/stable/c/610dbd8ac271aa36080aac50b928d700ee3fe4de","https://git.kernel.org/stable/c/246f80a0b17f8f582b2c0996db02998239057c65","https://git.kernel.org/stable/c/610dbd8ac271aa36080aac50b928d700ee3fe4de"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1872 | High | fixed |
|
A use-after-free vulnerability in the Linux Kernel io_uring system can be exploited to achieve local privilege escalation. The io_file_get_fixed function lacks the presence of ctx->uring_lock which can lead to a Use-After-Free vulnerability due a race condition with fixed files getting unregistered. We recommend upgrading past commit da24142b1ef9fd5d36b76e36bab328a5b27523e8. | ["http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=08681391b84da27133deefaaddefd0acfa90c2be","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=da24142b1ef9fd5d36b76e36bab328a5b27523e8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230601-0002/","http://packetstormsecurity.com/files/173087/Kernel-Live-Patch-Security-Notice-LSN-0095-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=08681391b84da27133deefaaddefd0acfa90c2be","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y\u0026id=da24142b1ef9fd5d36b76e36bab328a5b27523e8","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230601-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50156 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm: Avoid NULL dereference in msm_disp_state_print_regs() If the allocation in msm_disp_state_dump_regs() failed then `block->state` can be NULL. The msm_disp_state_print_regs() function _does_ have code to try to handle it with: if (*reg) dump_addr = *reg; ...but since "dump_addr" is initialized to NULL the above is actually a noop. The code then goes on to dereference `dump_addr`. Make the function print "Registers not stored" when it sees a NULL to solve this. Since we're touching the code, fix msm_disp_state_print_regs() not to pointlessly take a double-pointer and properly mark the pointer as `const`. Patchwork: https://patchwork.freedesktop.org/patch/619657/ | ["https://git.kernel.org/stable/c/293f53263266bc4340d777268ab4328a97f041fa","https://git.kernel.org/stable/c/42cf045086feae77b212f0f66e742b91a5b566b7","https://git.kernel.org/stable/c/563aa81fd66a4e7e6e551a0e02bcc23957cafe2f","https://git.kernel.org/stable/c/e8e9f2a12a6214080c8ea83220a596f6e1dedc6c","https://git.kernel.org/stable/c/f7ad916273483748582d97cfa31054ccb19224f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50160 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/cs8409: Fix possible NULL dereference If snd_hda_gen_add_kctl fails to allocate memory and returns NULL, then NULL pointer dereference will occur in the next line. Since dolphin_fixups function is a hda_fixup function which is not supposed to return any errors, add simple check before dereference, ignore the fail. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/21dc97d5086fdabbe278786bb0a03cbf2e26c793","https://git.kernel.org/stable/c/4e19aca8db696b6ba4dd8c73657405e15c695f14","https://git.kernel.org/stable/c/8971fd61210d75fd2af225621cd2fcc87eb1847c","https://git.kernel.org/stable/c/a5dd71a8b849626f42d08a5e73d382f2016fc7bc","https://git.kernel.org/stable/c/c9bd4a82b4ed32c6d1c90500a52063e6e341517f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50162 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: devmap: provide rxq after redirect rxq contains a pointer to the device from where the redirect happened. Currently, the BPF program that was executed after a redirect via BPF_MAP_TYPE_DEVMAP* does not have it set. This is particularly bad since accessing ingress_ifindex, e.g. SEC("xdp") int prog(struct xdp_md *pkt) { return bpf_redirect_map(&dev_redirect_map, 0, 0); } SEC("xdp/devmap") int prog_after_redirect(struct xdp_md *pkt) { bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS; } depends on access to rxq, so a NULL pointer gets dereferenced: <1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000 <1>[ 574.475188] #PF: supervisor read access in kernel mode <1>[ 574.475194] #PF: error_code(0x0000) - not-present page <6>[ 574.475199] PGD 0 P4D 0 <4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23 <4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023 <4>[ 574.475231] Workqueue: mld mld_ifc_work <4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b <4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206 <4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000 <4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0 <4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001 <4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000 <4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000 <4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000 <4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0 <4>[ 574.475303] PKRU: 55555554 <4>[ 574.475306] Call Trace: <4>[ 574.475313] <IRQ> <4>[ 574.475318] ? __die+0x23/0x70 <4>[ 574.475329] ? page_fault_oops+0x180/0x4c0 <4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490 <4>[ 574.475346] ? kmem_cache_free+0x257/0x280 <4>[ 574.475357] ? exc_page_fault+0x67/0x150 <4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30 <4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c <4>[ 574.475386] bq_xmit_all+0x158/0x420 <4>[ 574.475397] __dev_flush+0x30/0x90 <4>[ 574.475407] veth_poll+0x216/0x250 [veth] <4>[ 574.475421] __napi_poll+0x28/0x1c0 <4>[ 574.475430] net_rx_action+0x32d/0x3a0 <4>[ 574.475441] handle_softirqs+0xcb/0x2c0 <4>[ 574.475451] do_softirq+0x40/0x60 <4>[ 574.475458] </IRQ> <4>[ 574.475461] <TASK> <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70 <4>[ 574.475471] __dev_queue_xmit+0x268/0xe40 <4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420 <4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0 <4>[ 574.475502] ip6_finish_output2+0x2be/0x640 <4>[ 574.475512] ? nf_hook_slow+0x42/0xf0 <4>[ 574.475521] ip6_finish_output+0x194/0x300 <4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10 <4>[ 574.475538] mld_sendpack+0x17c/0x240 <4>[ 574.475548] mld_ifc_work+0x192/0x410 <4>[ 574.475557] process_one_work+0x15d/0x380 <4>[ 574.475566] worker_thread+0x29d/0x3a0 <4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10 <4>[ 574.475587] kthread+0xcd/0x100 <4>[ 574.475597] ? __pfx_kthread+0x10/0x10 <4>[ 574.475606] ret_from_fork+0x31/0x50 <4>[ 574.475615] ? __pfx_kthread+0x10/0x10 <4>[ 574.475623] ret_from_fork_asm+0x1a/0x ---truncated--- | ["https://git.kernel.org/stable/c/49454f09936a9a96edfb047156889879cb4001eb","https://git.kernel.org/stable/c/9167d1c274a336e4763eeb3f3f9cb763c55df5aa","https://git.kernel.org/stable/c/a778fbe087c19f4ece5f5fc14173328f070c3803","https://git.kernel.org/stable/c/ca9984c5f0ab3690d98b13937b2485a978c8dd73","https://git.kernel.org/stable/c/fe068afb868660fe683a8391c6c17ecbe2254922"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50163 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Make sure internal and UAPI bpf_redirect flags don't overlap The bpf_redirect_info is shared between the SKB and XDP redirect paths, and the two paths use the same numeric flag values in the ri->flags field (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means that if skb bpf_redirect_neigh() is used with a non-NULL params argument and, subsequently, an XDP redirect is performed using the same bpf_redirect_info struct, the XDP path will get confused and end up crashing, which syzbot managed to trigger. With the stack-allocated bpf_redirect_info, the structure is no longer shared between the SKB and XDP paths, so the crash doesn't happen anymore. However, different code paths using identically-numbered flag values in the same struct field still seems like a bit of a mess, so this patch cleans that up by moving the flag definitions together and redefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlap with the flags used for XDP. It also adds a BUILD_BUG_ON() check to make sure the overlap is not re-introduced by mistake. | ["https://git.kernel.org/stable/c/09d88791c7cd888d5195c84733caf9183dcfbd16","https://git.kernel.org/stable/c/0fca5ed4be8e8bfbfb9bd97845af596bab7192d3","https://git.kernel.org/stable/c/314dbee9fe4f5cee36435465de52c988d7caa466","https://git.kernel.org/stable/c/4e1e428533845d48828bd3875c0e92e8565b9962","https://git.kernel.org/stable/c/cec288e05ceac9a0d3a3a1fd279534b11844c826"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50182 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ | ["https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6","https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926","https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2","https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677","https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50189 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. | ["https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47","https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93","https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276","https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3","https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56692 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on node blkaddr in truncate_node() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace: truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909 f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288 f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856 evict+0x4e8/0x9b0 fs/inode.c:723 f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986 f2fs_create+0x357/0x530 fs/f2fs/namei.c:394 lookup_open fs/namei.c:3595 [inline] open_last_lookups fs/namei.c:3694 [inline] path_openat+0x1c03/0x3590 fs/namei.c:3930 do_filp_open+0x235/0x490 fs/namei.c:3960 do_sys_openat2+0x13e/0x1d0 fs/open.c:1415 do_sys_open fs/open.c:1430 [inline] __do_sys_openat fs/open.c:1446 [inline] __se_sys_openat fs/open.c:1441 [inline] __x64_sys_openat+0x247/0x2a0 fs/open.c:1441 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node(). | ["https://git.kernel.org/stable/c/0a5c8b3fbf6200f1c66062d307c9a52084917788","https://git.kernel.org/stable/c/27d6e7eff07f8cce8e83b162d8f21a07458c860d","https://git.kernel.org/stable/c/6babe00ccd34fc65b78ef8b99754e32b4385f23d","https://git.kernel.org/stable/c/c1077078ce4589b5e5387f6b0aaa0d4534b9eb57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56718 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: protect link down work from execute after lgr freed link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled. The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30 | ["https://git.kernel.org/stable/c/2627c3e8646932dfc7b9722c88c2e1ffcf7a9fb2","https://git.kernel.org/stable/c/2b33eb8f1b3e8c2f87cfdbc8cc117f6bdfabc6ec","https://git.kernel.org/stable/c/841b1824750d3b8d1dc0a96b14db4418b952abbc","https://git.kernel.org/stable/c/bec2f52866d511e94c1c37cd962e4382b1b1a299"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1249 | Medium | fixed |
|
A use-after-free flaw was found in the Linux kernel’s core dump subsystem. This flaw allows a local user to crash the system. Only if patch 390031c94211 ("coredump: Use the vma snapshot in fill_files_note") not applied yet, then kernel could be affected. | ["http://packetstormsecurity.com/files/171912/CentOS-Stream-9-Missing-Kernel-Security-Fix.html","https://patchwork.kernel.org/project/linux-fsdevel/patch/87iltzn3nd.fsf_-_%40email.froward.int.ebiederm.org/","http://packetstormsecurity.com/files/171912/CentOS-Stream-9-Missing-Kernel-Security-Fix.html","https://patchwork.kernel.org/project/linux-fsdevel/patch/87iltzn3nd.fsf_-_%40email.froward.int.ebiederm.org/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48920 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: get rid of warning on transaction commit when using flushoncommit When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...) The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] <TASK> [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] </TASK> [947.598553] ---[ end trace 644721052755541c ]--- This is because we started using writeback_inodes_sb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability. We can not just lock the sb->s_umount semaphore before calling writeback_inodes_sb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report. To fix this call try_to_writeback_inodes_sb() instead of writeback_inodes_sb(), because that will try to read lock sb->s_umount and then will only call writeback_inodes_sb() if it was able to lock it. This is fine because the cases where it can't read lock sb->s_umount are during a filesystem unmount or during a filesystem freeze - in those cases sb->s_umount is write locked and sync_filesystem() is called, which calls writeback_inodes_sb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere. An alternative would be to call btrfs_start_delalloc_roots() with a number of pages different from LONG_MAX, for example matching the number of delalloc bytes we currently have, in ---truncated--- | ["https://git.kernel.org/stable/c/850a77c999b81dd2724efd2684068d6f90db8c16","https://git.kernel.org/stable/c/a0f0cf8341e34e5d2265bfd3a7ad68342da1e2aa","https://git.kernel.org/stable/c/e4d044dbffcd570351f21c747fc77ff90aed7f2e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-44957 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock. | ["https://git.kernel.org/stable/c/1c682593096a487fd9aebc079a307ff7a6d054a3","https://git.kernel.org/stable/c/49f2a5da6785b2dbde93e291cae037662440346e","https://git.kernel.org/stable/c/c2775ae4d9227729f8ca9ee2a068f62a00d5ea9c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47671 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields. | ["https://git.kernel.org/stable/c/0c927dfc0b9bd177f7ab6ee59ef0c4ea06c110a7","https://git.kernel.org/stable/c/16e0ab9ed3ae7d19ca8ee718ba4e09d5c0f909ca","https://git.kernel.org/stable/c/51297ef7ad7824ad577337f273cd092e81a9fa08","https://git.kernel.org/stable/c/625fa77151f00c1bd00d34d60d6f2e710b3f9aad","https://git.kernel.org/stable/c/6c7fc36da021b13c34c572a26ba336cd102418f8","https://git.kernel.org/stable/c/ba6269e187aa1b1f20faf3c458831a0d6350304b","https://git.kernel.org/stable/c/e872738e670ddd63e19f22d0d784f0bdf26ecba5","https://git.kernel.org/stable/c/fa652318887da530f2f9dbd9b0ea4a087d05ee12"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47734 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx | ["https://git.kernel.org/stable/c/0cbfd45fbcf0cb26d85c981b91c62fe73cdee01c","https://git.kernel.org/stable/c/57b5fba55c6f8b1d83312a34bd656166fcd95658","https://git.kernel.org/stable/c/6b64197b4bf1a5703a8b105367baf20f1e627a75","https://git.kernel.org/stable/c/72e2c0825a480e19ee999cee9d018850d38c82b9","https://git.kernel.org/stable/c/c1be35e774f8ed415e01209fddd963c5a74e8e9f","https://git.kernel.org/stable/c/ccd3e6ff05e5236d1b9535f23f3e6622e0bb32b8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50096 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user. | ["https://git.kernel.org/stable/c/614bfb2050982d23d53d0d51c4079dba0437c883","https://git.kernel.org/stable/c/697e3ddcf1f8b68bd531fc34eead27c000bdf3e1","https://git.kernel.org/stable/c/73f75d2b5aee5a735cf64b8ab4543d5c20dbbdd9","https://git.kernel.org/stable/c/835745a377a4519decd1a36d6b926e369b3033e2","https://git.kernel.org/stable/c/8c3de9282dde21ce3c1bf1bde3166a4510547aa9","https://git.kernel.org/stable/c/ab4d113b6718b076046018292f821d5aa4b844f8","https://git.kernel.org/stable/c/fd9bb7e996bab9b9049fffe3f3d3b50dee191d27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50178 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq] | ["https://git.kernel.org/stable/c/2b7ec33e534f7a10033a5cf07794acf48b182bbe","https://git.kernel.org/stable/c/2f78e4a6d2702ac03c2bf2ed3a0e344e1fa9f967"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53050 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: Add encoder check in hdcp2_get_capability Add encoder check in intel_hdcp2_get_capability to avoid null pointer error. | ["https://git.kernel.org/stable/c/5b89dcf23575eb5bb95ce8d672cbc2232c2eb096","https://git.kernel.org/stable/c/d34f4f058edf1235c103ca9c921dc54820d14d40"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53051 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intel_hdcp_get_capability add a check to avoid kernel null pointer dereference. | ["https://git.kernel.org/stable/c/31b42af516afa1e184d1a9f9dd4096c54044269a","https://git.kernel.org/stable/c/4912e8fb3c37fb2dedf48d9c18bbbecd70e720f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53084 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler "finished" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context. | ["https://git.kernel.org/stable/c/b04ce1e718bd55302b52d05d6873e233cb3ec7a1","https://git.kernel.org/stable/c/cb86db12b290ed07d05df00d99fa150bb123e80e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53114 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability. | ["https://git.kernel.org/stable/c/00c713f84f477a85e524f34aad8fbd11a1c051f0","https://git.kernel.org/stable/c/a5ca1dc46a6b610dd4627d8b633d6c84f9724ef0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-39728 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: samsung: Fix UBSAN panic in samsung_clk_init() With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due to dereferencing `ctx->clk_data.hws` before setting `ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP <snip> Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ... | ["https://git.kernel.org/stable/c/00307934eb94aaa0a99addfb37b9fe206f945004","https://git.kernel.org/stable/c/0fef48f4a70e45a93e73c39023c3a6ea624714d6","https://git.kernel.org/stable/c/157de9e48007a20c65d02fc0229a16f38134a72d","https://git.kernel.org/stable/c/24307866e0ac0a5ddb462e766ceda5e27a6fbbe3","https://git.kernel.org/stable/c/4d29a6dcb51e346595a15b49693eeb728925ca43","https://git.kernel.org/stable/c/a1500b98cd81a32fdfb9bc63c33bb9f0c2a0a1bf","https://git.kernel.org/stable/c/d19d7345a7bcdb083b65568a11b11adffe0687af","https://git.kernel.org/stable/c/d974e177369c034984cece9d7d4fada9f8b9c740"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2153 | Medium | fixed |
|
A flaw was found in the Linux kernel’s KVM when attempting to set a SynIC IRQ. This issue makes it possible for a misbehaving VMM to write to SYNIC/STIMER MSRs, causing a NULL pointer dereference. This flaw allows an unprivileged local attacker on the host to issue specific ioctl calls, causing a kernel oops condition that results in a denial of service. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2069736","https://github.com/torvalds/linux/commit/00b5f37189d24ac3ed46cb7f11742094778c46ce","https://github.com/torvalds/linux/commit/7ec37d1cbe17d8189d9562178d8b29167fe1c31a","https://github.com/torvalds/linux/commit/b1e34d325397a33d97d845e312d7cf2a8b646b44","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.openwall.com/lists/oss-security/2022/06/22/1","https://bugzilla.redhat.com/show_bug.cgi?id=2069736","https://github.com/torvalds/linux/commit/00b5f37189d24ac3ed46cb7f11742094778c46ce","https://github.com/torvalds/linux/commit/7ec37d1cbe17d8189d9562178d8b29167fe1c31a","https://github.com/torvalds/linux/commit/b1e34d325397a33d97d845e312d7cf2a8b646b44","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.openwall.com/lists/oss-security/2022/06/22/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50191 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that. | ["https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439","https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9","https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8","https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09","https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50196 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` | ["https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417","https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a","https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6","https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c","https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53146 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent a potential integer overflow If the tag length is >= U32_MAX - 3 then the "length + 4" addition can result in an integer overflow. Address this by splitting the decoding into several steps so that decode_cb_compound4res() does not have to perform arithmetic on the unsafe length value. | ["https://git.kernel.org/stable/c/084f797dbc7e52209a4ab6dbc7f0109268754eb9","https://git.kernel.org/stable/c/3c5f545c9a1f8a1869246f6f3ae8c17289d6a841","https://git.kernel.org/stable/c/745f7ce5a95e783ba62fe774325829466aec2aa8","https://git.kernel.org/stable/c/7f33b92e5b18e904a481e6e208486da43e4dc841","https://git.kernel.org/stable/c/842f1c27a1aef5367e535f9e85c8c3b06352151a","https://git.kernel.org/stable/c/90adbae9dd158da8331d9fdd32077bd1af04f553","https://git.kernel.org/stable/c/ccd3394f9a7200d6b088553bf38e688620cd27af","https://git.kernel.org/stable/c/dde654cad08fdaac370febb161ec41eb58e9d2a2","https://git.kernel.org/stable/c/de53c5305184ca1333b87e695d329d1502d694ce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56739 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtc: check if __rtc_read_time was successful in rtc_timer_do_work() If the __rtc_read_time call fails,, the struct rtc_time tm; may contain uninitialized data, or an illegal date/time read from the RTC hardware. When calling rtc_tm_to_ktime later, the result may be a very large value (possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue, they will continually expire, may causing kernel softlockup. | ["https://git.kernel.org/stable/c/0d68e8514d9040108ff7d1b37ca71096674b6efe","https://git.kernel.org/stable/c/246f621d363988e7040f4546d20203dc713fa3e1","https://git.kernel.org/stable/c/39ad0a1ae17b54509cd9e93dcd8cec16e7c12d3f","https://git.kernel.org/stable/c/44b3257ff705d63d5f00ef8ed314a0eeb7ec37f2","https://git.kernel.org/stable/c/a1f0b4af90cc18b10261ecde56c6a56b22c75bd1","https://git.kernel.org/stable/c/dd4b1cbcc916fad5d10c2662b62def9f05e453d4","https://git.kernel.org/stable/c/e77bce0a8c3989b4173c36f4195122bca8f4a3e1","https://git.kernel.org/stable/c/e8ba8a2bc4f60a1065f23d6a0e7cbea945a0f40d","https://git.kernel.org/stable/c/fde56535505dde3336df438e949ef4742b6d6d6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48979 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix array index out of bound error in DCN32 DML [Why&How] LinkCapacitySupport array is indexed with the number of voltage states and not the number of max DPPs. Fix the error by changing the array declaration to use the correct (larger) array size of total number of voltage states. | ["https://git.kernel.org/stable/c/3d8a298b2e83b98042e6ec726e934f535b23e6aa","https://git.kernel.org/stable/c/aeffc8fb2174f017a10df114bc312f899904dc68"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50091 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally. | ["https://git.kernel.org/stable/c/0808ebf2f80b962e75741a41ced372a7116f1e26","https://git.kernel.org/stable/c/63ef073084c67878d7a92e15ad055172da3f05a3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4382 | Medium | N/A | A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side. | ["https://www.openwall.com/lists/oss-security/2022/12/14/5","https://www.openwall.com/lists/oss-security/2022/12/14/5"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3202 | High | fixed |
|
A NULL pointer dereference flaw in diFree in fs/jfs/inode.c in Journaled File System (JFS)in the Linux kernel. This could allow a local attacker to crash the system or leak kernel internal information. | ["https://github.com/torvalds/linux/commit/a53046291020ec41e09181396c1e829287b48d47","https://security.netapp.com/advisory/ntap-20221228-0007/","https://github.com/torvalds/linux/commit/a53046291020ec41e09181396c1e829287b48d47","https://security.netapp.com/advisory/ntap-20221228-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48866 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug. The root case is in missing validation check of actual number of endpoints. Code should not blindly access usb_host_interface::endpoint array, since it may contain less endpoints than code expects. Fix it by adding missing validaion check and print an error if number of endpoints do not match expected number | ["https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab","https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947","https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036","https://git.kernel.org/stable/c/3ffbe85cda7f523dad896bae08cecd8db8b555ab","https://git.kernel.org/stable/c/56185434e1e50acecee56d8f5850135009b87947","https://git.kernel.org/stable/c/fc3ef2e3297b3c0e2006b5d7b3d66965e3392036"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33743 | High | N/A | network backend may cause Linux netfront to use freed SKBs While adding logic to support XDP (eXpress Data Path), a code label was moved in a way allowing for SKBs having references (pointers) retained for further processing to nevertheless be freed. | ["http://www.openwall.com/lists/oss-security/2022/07/05/5","http://xenbits.xen.org/xsa/advisory-405.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-405.txt","http://www.openwall.com/lists/oss-security/2022/07/05/5","http://xenbits.xen.org/xsa/advisory-405.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-405.txt"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-26544 | High | fixed |
|
In the Linux kernel 6.0.8, there is a use-after-free in run_unpack in fs/ntfs3/run.c, related to a difference between NTFS sector size and media sector size. | ["https://bugzilla.suse.com/show_bug.cgi?id=1208697","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899","https://lkml.org/lkml/2023/2/20/128","https://security.netapp.com/advisory/ntap-20230316-0010/","https://bugzilla.suse.com/show_bug.cgi?id=1208697","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=887bfc546097fbe8071dac13b2fef73b77920899","https://lkml.org/lkml/2023/2/20/128","https://security.netapp.com/advisory/ntap-20230316-0010/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49290 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mac80211: fix potential double free on mesh join While commit 6a01afcf8468 ("mac80211: mesh: Free ie data when leaving mesh") fixed a memory leak on mesh leave / teardown it introduced a potential memory corruption caused by a double free when rejoining the mesh: ieee80211_leave_mesh() -> kfree(sdata->u.mesh.ie); ... ieee80211_join_mesh() -> copy_mesh_setup() -> old_ie = ifmsh->ie; -> kfree(old_ie); This double free / kernel panics can be reproduced by using wpa_supplicant with an encrypted mesh (if set up without encryption via "iw" then ifmsh->ie is always NULL, which avoids this issue). And then calling: $ iw dev mesh0 mesh leave $ iw dev mesh0 mesh join my-mesh Note that typically these commands are not used / working when using wpa_supplicant. And it seems that wpa_supplicant or wpa_cli are going through a NETDEV_DOWN/NETDEV_UP cycle between a mesh leave and mesh join where the NETDEV_UP resets the mesh.ie to NULL via a memcpy of default_mesh_setup in cfg80211_netdev_notifier_call, which then avoids the memory corruption, too. The issue was first observed in an application which was not using wpa_supplicant but "Senf" instead, which implements its own calls to nl80211. Fixing the issue by removing the kfree()'ing of the mesh IE in the mesh join function and leaving it solely up to the mesh leave to free the mesh IE. | ["https://git.kernel.org/stable/c/12e407a8ef17623823fd0c066fbd7f103953d28d","https://git.kernel.org/stable/c/273ebddc5fda2967492cb0b6cdd7d81cfb821b76","https://git.kernel.org/stable/c/3bbd0000d012f92aec423b224784fbf0f7bf40f8","https://git.kernel.org/stable/c/46bb87d40683337757a2f902fcd4244b32bb4e86","https://git.kernel.org/stable/c/4a2d4496e15ea5bb5c8e83b94ca8ca7fb045e7d3","https://git.kernel.org/stable/c/582d8c60c0c053684f7138875e8150d5749ffc17","https://git.kernel.org/stable/c/5d3ff9542a40ce034416bca03864709540a36016","https://git.kernel.org/stable/c/615716af8644813355e014314a0bc1e961250f5a","https://git.kernel.org/stable/c/c1d9c3628ef0a0ca197595d0f9e01cd3b5dda186"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48424 | High | fixed |
|
In the Linux kernel before 6.1.3, fs/ntfs3/inode.c does not validate the attribute name offset. An unhandled page fault may occur. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79","https://security.netapp.com/advisory/ntap-20230505-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79","https://security.netapp.com/advisory/ntap-20230505-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53023 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: nfc: Fix use-after-free in local_cleanup() Fix a use-after-free that occurs in kfree_skb() called from local_cleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, local_cleanup() called from nfc_llcp_unregister_device() frees local->rx_pending and decreases local->ref by kref_put() in nfc_llcp_local_put(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, local_cleanup() called from local_release() frees local->rx_pending again, which leads to the bug. Setting local->rx_pending to NULL in local_cleanup() could prevent use-after-free when local_cleanup() is called twice. Found by a modified version of syzkaller. BUG: KASAN: use-after-free in kfree_skb() Call Trace: dump_stack_lvl (lib/dump_stack.c:106) print_address_description.constprop.0.cold (mm/kasan/report.c:306) kasan_check_range (mm/kasan/generic.c:189) kfree_skb (net/core/skbuff.c:955) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172) nfc_llcp_local_put (net/nfc/llcp_core.c:181) llcp_sock_destruct (net/nfc/llcp_sock.c:959) __sk_destruct (net/core/sock.c:2133) sk_destruct (net/core/sock.c:2181) __sk_free (net/core/sock.c:2192) sk_free (net/core/sock.c:2203) llcp_sock_release (net/nfc/llcp_sock.c:646) __sock_release (net/socket.c:650) sock_close (net/socket.c:1365) __fput (fs/file_table.c:306) task_work_run (kernel/task_work.c:179) ptrace_notify (kernel/signal.c:2354) syscall_exit_to_user_mode_prepare (kernel/entry/common.c:278) syscall_exit_to_user_mode (kernel/entry/common.c:296) do_syscall_64 (arch/x86/entry/common.c:86) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106) Allocated by task 4719: kasan_save_stack (mm/kasan/common.c:45) __kasan_slab_alloc (mm/kasan/common.c:325) slab_post_alloc_hook (mm/slab.h:766) kmem_cache_alloc_node (mm/slub.c:3497) __alloc_skb (net/core/skbuff.c:552) pn533_recv_response (drivers/nfc/pn533/usb.c:65) __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671) usb_giveback_urb_bh (drivers/usb/core/hcd.c:1704) tasklet_action_common.isra.0 (kernel/softirq.c:797) __do_softirq (kernel/softirq.c:571) Freed by task 1901: kasan_save_stack (mm/kasan/common.c:45) kasan_set_track (mm/kasan/common.c:52) kasan_save_free_info (mm/kasan/genericdd.c:518) __kasan_slab_free (mm/kasan/common.c:236) kmem_cache_free (mm/slub.c:3809) kfree_skbmem (net/core/skbuff.c:874) kfree_skb (net/core/skbuff.c:931) local_cleanup (net/nfc/llcp_core.c:159) nfc_llcp_unregister_device (net/nfc/llcp_core.c:1617) nfc_unregister_device (net/nfc/core.c:1179) pn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846) pn533_usb_disconnect (drivers/nfc/pn533/usb.c:579) usb_unbind_interface (drivers/usb/core/driver.c:458) device_release_driver_internal (drivers/base/dd.c:1279) bus_remove_device (drivers/base/bus.c:529) device_del (drivers/base/core.c:3665) usb_disable_device (drivers/usb/core/message.c:1420) usb_disconnect (drivers/usb/core.c:2261) hub_event (drivers/usb/core/hub.c:5833) process_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) worker_thread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) ret_from_fork (arch/x86/entry/entry_64.S:301) | ["https://git.kernel.org/stable/c/4bb4db7f3187c6e3de6b229ffc87cdb30a2d22b6","https://git.kernel.org/stable/c/54f7be61584b8ec4c6df405f479495b9397bae4a","https://git.kernel.org/stable/c/7f129927feaf7c10b1c38bbce630172e9a08c834","https://git.kernel.org/stable/c/a59cdbda3714e11aa3ab579132864c4c8c6d54f9","https://git.kernel.org/stable/c/ad1baab3a5c03692d22ce446f38596a126377f6a","https://git.kernel.org/stable/c/b09ae26f08aaf2d85f96ea7f90ddd3387f62216f","https://git.kernel.org/stable/c/d3605282ec3502ec8847915eb2cf1f340493ff79"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-37838 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HSI: ssi_protocol: Fix use after free vulnerability in ssi_protocol Driver Due to Race Condition In the ssi_protocol_probe() function, &ssi->work is bound with ssip_xmit_work(), In ssip_pn_setup(), the ssip_pn_xmit() function within the ssip_pn_ops structure is capable of starting the work. If we remove the module which will call ssi_protocol_remove() to make a cleanup, it will free ssi through kfree(ssi), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ssip_xmit_work ssi_protocol_remove | kfree(ssi); | | struct hsi_client *cl = ssi->cl; | // use ssi Fix it by ensuring that the work is canceled before proceeding with the cleanup in ssi_protocol_remove(). | ["https://git.kernel.org/stable/c/4a8c29beb8a02b5a0a9d77d608aa14b6f88a6b86","https://git.kernel.org/stable/c/4b4194c9a7a8f92db39e8e86c85f4fb12ebbec4f","https://git.kernel.org/stable/c/58eb29dba712ab0f13af59ca2fe545f5ce360e78","https://git.kernel.org/stable/c/72972552d0d0bfeb2dec5daf343a19018db36ffa","https://git.kernel.org/stable/c/834e602d0cc7c743bfce734fad4a46cefc0f9ab1","https://git.kernel.org/stable/c/ae5a6a0b425e8f76a9f0677e50796e494e89b088","https://git.kernel.org/stable/c/d03abc1c2b21324550fa71e12d53e7d3498e0af6","https://git.kernel.org/stable/c/d58493832e284f066e559b8da5ab20c15a2801d3","https://git.kernel.org/stable/c/e3f88665a78045fe35c7669d2926b8d97b892c11"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48651 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following: ================================================================= UG: KASAN: slab-out-of-bounds in ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted 6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace: print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130 ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380 packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230 __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use "skb->head + skb->mac_header", out-of-bound access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac header in multicast to solve this out-of-bound bug. | ["https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca","https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be","https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4","https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7","https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638","https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241","https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef","https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4","https://git.kernel.org/stable/c/25efdbe5fe542c3063d1948cc4e98abcb57621ca","https://git.kernel.org/stable/c/346e94aa4a99378592c46d6a34c72703a32bd5be","https://git.kernel.org/stable/c/81225b2ea161af48e093f58e8dfee6d705b16af4","https://git.kernel.org/stable/c/8d06006c7eb75587d986da46c48ba9274f94e8e7","https://git.kernel.org/stable/c/ab4a733874ead120691e8038272d22f8444d3638","https://git.kernel.org/stable/c/b583e6b25bf9321c91154f6c78d2173ef12c4241","https://git.kernel.org/stable/c/bffcdade259c05ab3436b5fab711612093c275ef","https://git.kernel.org/stable/c/e2b46cd5796f083e452fbc624f65b80328b0c1a4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48842 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: Fix race condition during interface enslave Commit 5dbbbd01cbba83 ("ice: Avoid RTNL lock when re-creating auxiliary device") changes a process of re-creation of aux device so ice_plug_aux_dev() is called from ice_service_task() context. This unfortunately opens a race window that can result in dead-lock when interface has left LAG and immediately enters LAG again. Reproducer: ``` #!/bin/sh ip link add lag0 type bond mode 1 miimon 100 ip link set lag0 for n in {1..10}; do echo Cycle: $n ip link set ens7f0 master lag0 sleep 1 ip link set ens7f0 nomaster done ``` This results in: [20976.208697] Workqueue: ice ice_service_task [ice] [20976.213422] Call Trace: [20976.215871] __schedule+0x2d1/0x830 [20976.219364] schedule+0x35/0xa0 [20976.222510] schedule_preempt_disabled+0xa/0x10 [20976.227043] __mutex_lock.isra.7+0x310/0x420 [20976.235071] enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core] [20976.251215] ib_enum_roce_netdev+0xa4/0xe0 [ib_core] [20976.256192] ib_cache_setup_one+0x33/0xa0 [ib_core] [20976.261079] ib_register_device+0x40d/0x580 [ib_core] [20976.266139] irdma_ib_register_device+0x129/0x250 [irdma] [20976.281409] irdma_probe+0x2c1/0x360 [irdma] [20976.285691] auxiliary_bus_probe+0x45/0x70 [20976.289790] really_probe+0x1f2/0x480 [20976.298509] driver_probe_device+0x49/0xc0 [20976.302609] bus_for_each_drv+0x79/0xc0 [20976.306448] __device_attach+0xdc/0x160 [20976.310286] bus_probe_device+0x9d/0xb0 [20976.314128] device_add+0x43c/0x890 [20976.321287] __auxiliary_device_add+0x43/0x60 [20976.325644] ice_plug_aux_dev+0xb2/0x100 [ice] [20976.330109] ice_service_task+0xd0c/0xed0 [ice] [20976.342591] process_one_work+0x1a7/0x360 [20976.350536] worker_thread+0x30/0x390 [20976.358128] kthread+0x10a/0x120 [20976.365547] ret_from_fork+0x1f/0x40 ... [20976.438030] task:ip state:D stack: 0 pid:213658 ppid:213627 flags:0x00004084 [20976.446469] Call Trace: [20976.448921] __schedule+0x2d1/0x830 [20976.452414] schedule+0x35/0xa0 [20976.455559] schedule_preempt_disabled+0xa/0x10 [20976.460090] __mutex_lock.isra.7+0x310/0x420 [20976.464364] device_del+0x36/0x3c0 [20976.467772] ice_unplug_aux_dev+0x1a/0x40 [ice] [20976.472313] ice_lag_event_handler+0x2a2/0x520 [ice] [20976.477288] notifier_call_chain+0x47/0x70 [20976.481386] __netdev_upper_dev_link+0x18b/0x280 [20976.489845] bond_enslave+0xe05/0x1790 [bonding] [20976.494475] do_setlink+0x336/0xf50 [20976.502517] __rtnl_newlink+0x529/0x8b0 [20976.543441] rtnl_newlink+0x43/0x60 [20976.546934] rtnetlink_rcv_msg+0x2b1/0x360 [20976.559238] netlink_rcv_skb+0x4c/0x120 [20976.563079] netlink_unicast+0x196/0x230 [20976.567005] netlink_sendmsg+0x204/0x3d0 [20976.570930] sock_sendmsg+0x4c/0x50 [20976.574423] ____sys_sendmsg+0x1eb/0x250 [20976.586807] ___sys_sendmsg+0x7c/0xc0 [20976.606353] __sys_sendmsg+0x57/0xa0 [20976.609930] do_syscall_64+0x5b/0x1a0 [20976.613598] entry_SYSCALL_64_after_hwframe+0x65/0xca 1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev() is called from ice_service_task() context, aux device is created and associated device->lock is taken. 2. Command 'ip link ... set master...' calls ice's notifier under RTNL lock and that notifier calls ice_unplug_aux_dev(). That function tries to take aux device->lock but this is already taken by ice_plug_aux_dev() in step 1 3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already taken in step 2 4. Dead-lock The patch fixes this issue by following changes: - Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev() call in ice_service_task() - The bit is checked in ice_clear_rdma_cap() and only if it is not set then ice_unplug_aux_dev() is called. If it is set (in other words plugging of aux device was requested and ice_plug_aux_dev() is potentially running) then the function only clears the ---truncated--- | ["https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc","https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef","https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc","https://git.kernel.org/stable/c/5cb1ebdbc4342b1c2ce89516e19808d64417bdbc","https://git.kernel.org/stable/c/a9bbacc53d1f5ed8febbfdf31401d20e005f49ef","https://git.kernel.org/stable/c/e1014fc5572375658fa421531cedb6e084f477dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53210 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct() Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount (skb->users) and iucv_sock_recvmsg() does not decrement skb refcount at exit. This results in skb memory leak in skb_queue_purge() and WARN_ON in iucv_sock_destruct() during socket close. To fix this decrease skb refcount by one if MSG_PEEK is set in order to prevent memory leak and WARN_ON. WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv] CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1 Hardware name: IBM 3931 A01 704 (z/VM 7.3.0) Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv] | ["https://git.kernel.org/stable/c/42251c2d1ef1cb0822638bebb87ad9120c759673","https://git.kernel.org/stable/c/783c2c6e61c5a04eb8baea598753d5fa174dbe85","https://git.kernel.org/stable/c/934326aef7ac4652f81c69d18bf44eebaefc39c3","https://git.kernel.org/stable/c/9f603e66e1c59c1d25e60eb0636cb307d190782e","https://git.kernel.org/stable/c/ebaf81317e42aa990ad20b113cfe3a7b20d4e937"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56588 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: hisi_sas: Create all dump files during debugfs initialization For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump. Therefore, when the dump is triggered while the driver is unbind, the following hang occurs: [67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855] ESR = 0x0000000096000004 [67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125] SET = 0, FnV = 0 [67840.878291] EA = 0, S1PTW = 0 [67840.881545] FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : down_write+0x30/0x98 [67841.007546] lr : start_creating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456] down_write+0x30/0x98 [67841.096017] start_creating.part.0+0x60/0x198 [67841.100613] debugfs_create_dir+0x48/0x1f8 [67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw] [67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw] [67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw] [67841.125115] full_proxy_write+0x68/0xc8 [67841.129175] vfs_write+0xd8/0x3f0 [67841.132708] ksys_write+0x70/0x108 [67841.136317] __arm64_sys_write+0x24/0x38 [67841.140440] invoke_syscall+0x50/0x128 [67841.144385] el0_svc_common.constprop.0+0xc8/0xf0 [67841.149273] do_el0_svc+0x24/0x38 [67841.152773] el0_svc+0x38/0xd8 [67841.156009] el0t_64_sync_handler+0xc0/0xc8 [67841.160361] el0t_64_sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]--- To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping. | ["https://git.kernel.org/stable/c/6c55f99123075e5429850b41b06f7dfffcb708eb","https://git.kernel.org/stable/c/7c8c50c9855a9e1b0d1e3680e5ad839002a9deb5","https://git.kernel.org/stable/c/9f564f15f88490b484e02442dc4c4b11640ea172"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48955 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: thunderbolt: fix memory leak in tbnet_open() When tb_ring_alloc_rx() failed in tbnet_open(), ida that allocated in tb_xdomain_alloc_out_hopid() is not released. Add tb_xdomain_release_out_hopid() to the error path to release ida. | ["https://git.kernel.org/stable/c/b9274dbe399952a8175db2e1ee148b7c9ba2b538","https://git.kernel.org/stable/c/ed14e5903638f6eb868e3e2b4e610985e6a6c876","https://git.kernel.org/stable/c/ed6e955f3b7e0e622c080f4bcb5427a5e1af4c2a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48957 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove() The cmd_buff needs to be freed when error happened in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove(). | ["https://git.kernel.org/stable/c/4fad22a1281c500f15b172c9d261eff347ca634b","https://git.kernel.org/stable/c/54d830e24247fa8361b016dd2069362866f45cb6","https://git.kernel.org/stable/c/785ee7a82297e1512d9061aae91699212ed65796"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48965 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio/rockchip: fix refcount leak in rockchip_gpiolib_register() The node returned by of_get_parent() with refcount incremented, of_node_put() needs be called when finish using it. So add it in the end of of_pinctrl_get(). | ["https://git.kernel.org/stable/c/033c79b7ee8a7bf1c1a13ac3addc91184425cbae","https://git.kernel.org/stable/c/5cb8f1a784fd6115be58282fe15105572319d8be","https://git.kernel.org/stable/c/63ff545af73f759d1bd04198af8ed8577fb739fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48968 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix potential memory leak in otx2_init_tc() In otx2_init_tc(), if rhashtable_init() failed, it does not free tc->tc_entries_bitmap which is allocated in otx2_tc_alloc_ent_bitmap(). | ["https://git.kernel.org/stable/c/db5ec358cf4ef0ab382ee733d05f018e8bef9462","https://git.kernel.org/stable/c/eefd8953a74822cb72006632b9ee9dd95f92c146","https://git.kernel.org/stable/c/fbf33f5ac76f2cdb47ad9763f620026d5cfa57ce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53161 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: EDAC/bluefield: Fix potential integer overflow The 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idx left-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as 32-bits wide the left-shift operation truncates the upper 16 bits of information during the calculation of the SMC argument. The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent any potential integer overflow, i.e. loss of data from upper 16 bits. | ["https://git.kernel.org/stable/c/000930193fe5eb79ce5563ee2e9ddb0c6e4e1bb5","https://git.kernel.org/stable/c/1fe774a93b46bb029b8f6fa9d1f25affa53f06c6","https://git.kernel.org/stable/c/4ad7033de109d0fec99086f352f58a3412e378b8","https://git.kernel.org/stable/c/578ca89b04680145d41011e7cec8806fefbb59e7","https://git.kernel.org/stable/c/8cc31cfa36ff37aff399b72faa2ded58110112ae","https://git.kernel.org/stable/c/ac6ebb9edcdb7077e841862c402697c4c48a7c0a","https://git.kernel.org/stable/c/e0269ea7a628fdeddd65b92fe29c09655dbb80b9","https://git.kernel.org/stable/c/fdb90006184aa84c7b4e09144ed0936d4e1891a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53180 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Add sanity NULL check for the default mmap fault handler A driver might allow the mmap access before initializing its runtime->dma_area properly. Add a proper NULL check before passing to virt_to_page() for avoiding a panic. | ["https://git.kernel.org/stable/c/0c4c9bf5eab7bee6b606f2abb0993e933b5831a0","https://git.kernel.org/stable/c/832efbb74b1578e3737d593a204d42af8bd1b81b","https://git.kernel.org/stable/c/8799f4332a9fd812eadfbc32fc5104d6292f754f","https://git.kernel.org/stable/c/bc200027ee92fba84f1826494735ed675f3aa911","https://git.kernel.org/stable/c/d2913a07d9037fe7aed4b7e680684163eaed6bc4","https://git.kernel.org/stable/c/f0ce9e24eff1678c16276f9717f26a78202506a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53215 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init() There's issue as follows: RPC: Registered rdma transport module. RPC: Registered rdma backchannel transport module. RPC: Unregistered rdma transport module. RPC: Unregistered rdma backchannel transport module. BUG: unable to handle page fault for address: fffffbfff80c609a PGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI RIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0 Call Trace: <TASK> __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 </TASK> If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will not destroy the percpu counters which init in svc_rdma_proc_init(). If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the 'percpu_counters' list. The above issue may occur once the module is removed. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memory leakage occurs. To solve above issue just destroy all percpu counters when register_sysctl() return NULL. | ["https://git.kernel.org/stable/c/1c9a99c89e45b22eb556fd2f3f729f2683f247d5","https://git.kernel.org/stable/c/20322edcbad82a60321a8615a99ca73a9611115f","https://git.kernel.org/stable/c/94d2d6d398706ab7218a26d61e12919c4b498e09","https://git.kernel.org/stable/c/a12c897adf40b6e2b4a56e6912380c31bd7b2479","https://git.kernel.org/stable/c/ce89e742a4c12b20f09a43fec1b21db33f2166cd","https://git.kernel.org/stable/c/ebf47215d46992caea660ec01cd618005d9e687a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56567 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ad7780: fix division by zero in ad7780_write_raw() In the ad7780_write_raw() , val2 can be zero, which might lead to a division by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw() is based on iio_info's write_raw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero. | ["https://git.kernel.org/stable/c/022e13518ba6cc1b4fdd291f49e4f57b2d5718e0","https://git.kernel.org/stable/c/18fb33df1de83a014d7f784089f9b124facc157f","https://git.kernel.org/stable/c/68e79b848196a0b0ec006009cc69da1f835d1ae8","https://git.kernel.org/stable/c/7e3a8ea3d1ada7f707de5d9d504774b4191eab66","https://git.kernel.org/stable/c/afc1e3c00b3f5f0b4f1bc3e974fb9803cb938a90","https://git.kernel.org/stable/c/c174b53e95adf2eece2afc56cd9798374919f99a","https://git.kernel.org/stable/c/f25a9f1df1f6738acf1fa05595fb6060a2c08ff1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56569 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix regression with module command in stack_trace_filter When executing the following command: # echo "write*:mod:ext3" > /sys/kernel/tracing/stack_trace_filter The current mod command causes a null pointer dereference. While commit 0f17976568b3f ("ftrace: Fix regression with module command in stack_trace_filter") has addressed part of the issue, it left a corner case unhandled, which still results in a kernel crash. | ["https://git.kernel.org/stable/c/19cacabdd5a8487ae566cbecb4d03bcb038a067e","https://git.kernel.org/stable/c/43ca32ce12888fb0eeb2d74dfc558dea60d3473e","https://git.kernel.org/stable/c/45af52e7d3b8560f21d139b3759735eead8b1653","https://git.kernel.org/stable/c/5dabb7af57bc72308a6e2e81a5dd756eef283803","https://git.kernel.org/stable/c/7ae27880de3482e063fcc1f72d9a298d0d391407","https://git.kernel.org/stable/c/885109aa0c70639527dd6a65c82e63c9ac055e3d","https://git.kernel.org/stable/c/8a92dc4df89c50bdb26667419ea70e0abbce456e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56574 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: ts2020: fix null-ptr-deref in ts2020_probe() KASAN reported a null-ptr-deref issue when executing the following command: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ... The cause of the problem is that when using sysfs to dynamically register an i2c device, there is no platform data, but the probe process of ts2020 needs to use platform data, resulting in a null pointer being accessed. Solve this problem by adding checks to platform data. | ["https://git.kernel.org/stable/c/4a058b34b52ed3feb1f3ff6fd26aefeeeed20cba","https://git.kernel.org/stable/c/5a53f97cd5977911850b695add057f9965c1a2d6","https://git.kernel.org/stable/c/901070571bc191d1d8d7a1379bc5ba9446200999","https://git.kernel.org/stable/c/a2ed3b780f34e4a6403064208bc2c99d1ed85026","https://git.kernel.org/stable/c/b6208d1567f929105011bcdfd738f59a6bdc1088","https://git.kernel.org/stable/c/ced1c04e82e3ecc246b921b9733f0df0866aa50d","https://git.kernel.org/stable/c/dc03866b5f4aa2668946f8384a1e5286ae53bbaa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56587 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: leds: class: Protect brightness_show() with led_cdev->led_access mutex There is NULL pointer issue observed if from Process A where hid device being added which results in adding a led_cdev addition and later a another call to access of led_cdev attribute from Process B can result in NULL pointer issue. Use mutex led_cdev->led_access to protect access to led->cdev and its attribute inside brightness_show() and max_brightness_show() and also update the comment for mutex that it should be used to protect the led class device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74 [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 3313.874301][ T4013] Mem abort info: [ 3313.874303][ T4013] ESR = 0x0000000096000006 [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits [ 3313.874307][ T4013] SET = 0, FnV = 0 [ 3313.874309][ T4013] EA = 0, S1PTW = 0 [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault [ 3313.874313][ T4013] Data abort info: [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000 .. [ 3313.874332][ T4013] Dumping ftrace buffer: [ 3313.874334][ T4013] (ftrace buffer empty) .. .. [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74 [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60 [ 3313.874656][ T4013] sp : ffffffc0b910bbd0 .. .. [ 3313.874685][ T4013] Call trace: [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74 [ 3313.874690][ T4013] brightness_show+0x20/0x4c [ 3313.874692][ T4013] dev_attr_show+0x38/0x74 [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130 [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54 [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4 [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8 [ 3313.874711][ T4013] ksys_read+0x78/0xe8 [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c [ 3313.874718][ T4013] invoke_syscall+0x58/0x114 [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0 [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28 [ 3313.874727][ T4013] el0_svc+0x38/0x68 [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac | ["https://git.kernel.org/stable/c/4ca7cd938725a4050dcd62ae9472e931d603118d","https://git.kernel.org/stable/c/50d9f68e4adf86901cbab1bd5b91f710aa9141b9","https://git.kernel.org/stable/c/84b42d5b5fcd767c9b7f30b0b32065ed949fe804","https://git.kernel.org/stable/c/b8283d52ed15c02bb2eb9b1b8644dcc34f8e98f1","https://git.kernel.org/stable/c/bb4a6236a430cfc3713f470f3a969f39d6d4ca25","https://git.kernel.org/stable/c/ddcfc5708da9972ac23a9121b3d819b0a53d6f21","https://git.kernel.org/stable/c/f6d6fb563e4be245a17bc4261a4b294e8bf8a31e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56593 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw() This patch fixes a NULL pointer dereference bug in brcmfmac that occurs when a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBs are sent from the pkt queue. The problem is the number of entries in the pre-allocated sgtable, it is nents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1. Given the default [rt]xglom_size=32 it's actually 35 which is too small. Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKB is added for each original SKB if tailroom isn't enough to hold tail_pad. At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop" in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next return NULL and this causes the oops. The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handle the worst-case. Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464 additional bytes of memory. | ["https://git.kernel.org/stable/c/07c020c6d14d29e5a3ea4e4576b8ecf956a80834","https://git.kernel.org/stable/c/342f87d263462c2670b77ea9a32074cab2ac6fa1","https://git.kernel.org/stable/c/34941321b516bd7c6103bd01287d71a1804d19d3","https://git.kernel.org/stable/c/67a25ea28f8ec1da8894f2f115d01d3becf67dc7","https://git.kernel.org/stable/c/7522d7d745d13fbeff3350fe6aa56c8dae263571","https://git.kernel.org/stable/c/857282b819cbaa0675aaab1e7542e2c0579f52d7","https://git.kernel.org/stable/c/dfb3f9d3f602602de208da7bdcc0f6d5ee74af68"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56629 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: wacom: fix when get product name maybe null pointer Due to incorrect dev->product reporting by certain devices, null pointer dereferences occur when dev->product is empty, leading to potential system crashes. This issue was found on EXCELSIOR DL37-D05 device with Loongson-LS3A6000-7A2000-DL37 motherboard. Kernel logs: [ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci [ 56.671638] usb 4-3: string descriptor 0 read error: -22 [ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07 [ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0 [ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80 [ 56.697732] Oops[#1]: [ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015 [ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024 [ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0 [ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000 [ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000 [ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005 [ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000 [ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028 [ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000 [ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000 [ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom] [ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120 [ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE) [ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) [ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 56.697835] BADV: 0000000000000000 [ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit [ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3) [ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000 [ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000 [ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0 [ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c [ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440 [ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0 [ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c [ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000 [ 56.697931] 90000001000bb8d0 ---truncated--- | ["https://git.kernel.org/stable/c/2cd323c55bd3f356bf23ae1b4c20100abcdc29d6","https://git.kernel.org/stable/c/2ed3e3a3ac06af8a6391c3d6a7791b7967d7d43a","https://git.kernel.org/stable/c/5912a921289edb34d40aeab32ea6d52d41e75fed","https://git.kernel.org/stable/c/59548215b76be98cf3422eea9a67d6ea578aca3d","https://git.kernel.org/stable/c/a7f0509556fa2f9789639dbcee9eed46e471ccef","https://git.kernel.org/stable/c/d031eef3cc2e3bf524509e38fb898e5335c85c96","https://git.kernel.org/stable/c/e689bc6697a7fcebd4a945ab0b1e1112c76024d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56648 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hsr: avoid potential out-of-bound access in fill_frame_info() syzbot is able to feed a packet with 14 bytes, pretending it is a vlan one. Since fill_frame_info() is relying on skb->mac_len already, extend the check to cover this case. BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:709 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 fill_frame_info net/hsr/hsr_forward.c:709 [inline] hsr_forward_skb+0x9ee/0x3b10 net/hsr/hsr_forward.c:724 hsr_dev_xmit+0x2f0/0x350 net/hsr/hsr_device.c:235 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3606 __dev_queue_xmit+0x366a/0x57d0 net/core/dev.c:4434 dev_queue_xmit include/linux/netdevice.h:3168 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x91ae/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1323 [inline] alloc_skb_with_frags+0xc8/0xd00 net/core/skbuff.c:6612 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2881 packet_alloc_skb net/packet/af_packet.c:2995 [inline] packet_snd net/packet/af_packet.c:3089 [inline] packet_sendmsg+0x74c6/0xa6f0 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:726 __sys_sendto+0x594/0x750 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2200 x64_sys_call+0x346a/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f | ["https://git.kernel.org/stable/c/3c215663b3e27a3b08cefcaea623ff54c70c8035","https://git.kernel.org/stable/c/6bb5c8ebc99f0671dbd3c9408ebaf935c3951186","https://git.kernel.org/stable/c/7ea527fbd7b94d0bee64a0a7e98279bcc654b322","https://git.kernel.org/stable/c/aa632691c722a123e47ccd05a3afdd5f87a36061","https://git.kernel.org/stable/c/b9653d19e556c6afd035602927a93d100a0d7644","https://git.kernel.org/stable/c/c6e778901d0055356c4fb223058364cae731494a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56659 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: lapb: increase LAPB_HEADER_LEN It is unclear if net/lapb code is supposed to be ready for 8021q. We can at least avoid crashes like the following : skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282 RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60 R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140 R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016 FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 | ["https://git.kernel.org/stable/c/03e661b5e7aa1124f24054df9ab2ee5cb2178973","https://git.kernel.org/stable/c/2b351355bbd50ae25d096785b6eb31998d2bf765","https://git.kernel.org/stable/c/3aa2ef7ffd0451e8f81c249d2a2a68283c6bc700","https://git.kernel.org/stable/c/76d856f03d0290cf5392364ecdf74c15ee16b8fd","https://git.kernel.org/stable/c/a6d75ecee2bf828ac6a1b52724aba0a977e4eaf4","https://git.kernel.org/stable/c/c21c7c1c00bcc60cf752ec491bdfd47693f4d3c7","https://git.kernel.org/stable/c/f0949199651bc87c5ed2c12a7323f441f1af6fe9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56670 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointer Considering that in some extreme cases, when u_serial driver is accessed by multiple threads, Thread A is executing the open operation and calling the gs_open, Thread B is executing the disconnect operation and calling the gserial_disconnect function,The port->port_usb pointer will be set to NULL. E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Crash This causes thread A to access a null pointer (port->port_usb is null) when calling the gs_free_requests function, causing a crash. If port_usb is NULL, the release request will be skipped as it will be done by gserial_disconnect. So add a null pointer check to gs_start_io before attempting to access the value of the pointer port->port_usb. Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68 | ["https://git.kernel.org/stable/c/1247e1df086aa6c17ab53cd1bedce70dd7132765","https://git.kernel.org/stable/c/28b3c03a6790de1f6f2683919ad657840f0f0f58","https://git.kernel.org/stable/c/4cfbca86f6a8b801f3254e0e3c8f2b1d2d64be2b","https://git.kernel.org/stable/c/4efdfdc32d8d6307f968cd99f1db64468471bab1","https://git.kernel.org/stable/c/8ca07a3d18f39b1669927ef536e485787e856df6","https://git.kernel.org/stable/c/c83213b6649d22656b3a4e92544ceeea8a2c6c07","https://git.kernel.org/stable/c/dd6b0ca6025f64ccb465a6a3460c5b0307ed9c44"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56720 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Several fixes to bpf_msg_pop_data Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG. | ["https://git.kernel.org/stable/c/275a9f3ef8fabb0cb282a62b9e164dedba7284c5","https://git.kernel.org/stable/c/5d609ba262475db450ba69b8e8a557bd768ac07a","https://git.kernel.org/stable/c/785180bed9879680d8e5c5e1b54c8ae8d948f4c8","https://git.kernel.org/stable/c/98c7ea7d11f2588e8197db042e0291e4ac8f8346","https://git.kernel.org/stable/c/d26d977633d1d0b8bf9407278189bd0a8d973323","https://git.kernel.org/stable/c/d3f5763b3062514a234114e97bbde74d8d702449","https://git.kernel.org/stable/c/e1f54c61c4c9a5244eb8159dce60d248f7d97b32","https://git.kernel.org/stable/c/f58d3aa457e77a3d9b3df2ab081dcf9950f6029f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56723 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. | ["https://git.kernel.org/stable/c/0350d783ab888cb1cb48ced36cc28b372723f1a4","https://git.kernel.org/stable/c/61d590d7076b50b6ebdea1f3b83bb041c01fc482","https://git.kernel.org/stable/c/6ea17c03edc7ed0aabb1431eb26e2f94849af68a","https://git.kernel.org/stable/c/7ba45b8bc62e64da524d45532107ae93eb33c93c","https://git.kernel.org/stable/c/897713c9d24f6ec394585abfcf259a6e5cad22c8","https://git.kernel.org/stable/c/b3d45c19bcffb9a9a821df759f60be39d88c19f4","https://git.kernel.org/stable/c/bb6642d4b3136359b5b620049f76515876e6127e","https://git.kernel.org/stable/c/d4cc78bd6a25accb7ae2ac9fc445d1e1deda4a62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56575 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Ensure power suppliers be suspended before detach them The power suppliers are always requested to suspend asynchronously, dev_pm_domain_detach() requires the caller to ensure proper synchronization of this function with power management callbacks. otherwise the detach may led to kernel panic, like below: [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040 [ 1457.116777] Mem abort info: [ 1457.119589] ESR = 0x0000000096000004 [ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits [ 1457.128692] SET = 0, FnV = 0 [ 1457.131764] EA = 0, S1PTW = 0 [ 1457.134920] FSC = 0x04: level 0 translation fault [ 1457.139812] Data abort info: [ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000 [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000 [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec] [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66 [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT) [ 1457.199236] Workqueue: pm pm_runtime_work [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290 [ 1457.214886] lr : __rpm_callback+0x48/0x1d8 [ 1457.218968] sp : ffff80008250bc50 [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000 [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240 [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008 [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674 [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002 [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0 [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000 [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000 [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000 [ 1457.293510] Call trace: [ 1457.295946] genpd_runtime_suspend+0x20/0x290 [ 1457.300296] __rpm_callback+0x48/0x1d8 [ 1457.304038] rpm_callback+0x6c/0x78 [ 1457.307515] rpm_suspend+0x10c/0x570 [ 1457.311077] pm_runtime_work+0xc4/0xc8 [ 1457.314813] process_one_work+0x138/0x248 [ 1457.318816] worker_thread+0x320/0x438 [ 1457.322552] kthread+0x110/0x114 [ 1457.325767] ret_from_fork+0x10/0x20 | ["https://git.kernel.org/stable/c/12914fd765ba4f9d6a9a50439e8dd2e9f91423f2","https://git.kernel.org/stable/c/2f86d104539fab9181ea7b5721f40e7b92a8bf67","https://git.kernel.org/stable/c/b7a830bbc25da0f641e3ef2bac3b1766b2777a8b","https://git.kernel.org/stable/c/f3c4e088ec01cae45931a18ddf7cae0f4d72e1c5","https://git.kernel.org/stable/c/fd0af4cd35da0eb550ef682b71cda70a4e36f6b9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56578 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: imx-jpeg: Set video drvdata before register video device The video drvdata should be set before the video device is registered, otherwise video_drvdata() may return NULL in the open() file ops, and led to oops. | ["https://git.kernel.org/stable/c/5ade59d28eade49194eb09765afdeb0ba717c39a","https://git.kernel.org/stable/c/68efeff2f7fccdfedc55f92e92be32997127d16e","https://git.kernel.org/stable/c/b88556e82dc18cb708744d062770853a2d5095b2","https://git.kernel.org/stable/c/d2b7ecc26bd5406d5ba927be1748aa99c568696c","https://git.kernel.org/stable/c/f68bb1210fbea252552d97242757f69a219e942b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56622 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: sysfs: Prevent div by zero Prevent a division by 0 when monitoring is not enabled. | ["https://git.kernel.org/stable/c/0069928727c2e95ca26c738fbe6e4b241aeaaf08","https://git.kernel.org/stable/c/7b21233e5f72d10f08310689f993c1dbdfde9f2c","https://git.kernel.org/stable/c/87bf3ea841a5d77beae6bb85af36b2b3848407ee","https://git.kernel.org/stable/c/9c191055c7abea4912fdb83cb9b261732b25a0c8","https://git.kernel.org/stable/c/eb48e9fc0028bed94a40a9352d065909f19e333c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56722 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix cpu stuck caused by printings during reset During reset, cmd to destroy resources such as qp, cq, and mr may fail, and error logs will be printed. When a large number of resources are destroyed, there will be lots of printings, and it may lead to a cpu stuck. Delete some unnecessary printings and replace other printing functions in these paths with the ratelimited version. | ["https://git.kernel.org/stable/c/31c6fe9b79ed42440094f2367897aea0c0ce96ec","https://git.kernel.org/stable/c/323275ac2ff15b2b7b3eac391ae5d8c5a3c3a999","https://git.kernel.org/stable/c/a0e4c78770faa0d56d47391476fe1d827e72eded","https://git.kernel.org/stable/c/b4ba31e5aaffbda9b22d9a35c40b16dc39e475a6","https://git.kernel.org/stable/c/e2e64f9c42c717beb459ab209ec1c4baa73d3760"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49970 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 | ["https://git.kernel.org/stable/c/b219b46ad42df1dea9258788bcfea37181f3ccb2","https://git.kernel.org/stable/c/bdf606810210e8e07a0cdf1af3c467291363b295"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56544 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udmabuf: change folios array from kmalloc to kvmalloc When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine, page_alloc only support 4MB. If above this, trigger this warn and return NULL. udmabuf can change size limit, if change it to 3072(3GB), and then alloc 3GB udmabuf, will fail create. [ 4080.876581] ------------[ cut here ]------------ [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Call Trace: [ 4080.879473] <TASK> [ 4080.879473] ? __alloc_pages+0x2c8/0x350 [ 4080.879475] ? __warn.cold+0x8e/0xe8 [ 4080.880647] ? __alloc_pages+0x2c8/0x350 [ 4080.880909] ? report_bug+0xff/0x140 [ 4080.881175] ? handle_bug+0x3c/0x80 [ 4080.881556] ? exc_invalid_op+0x17/0x70 [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20 [ 4080.882077] ? udmabuf_create+0x131/0x400 Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB memory, each array entry is pointer(8byte), so can save 524288 pages(2GB). Further more, costly order(order 3) may not be guaranteed that it can be applied for, due to fragmentation. This patch change udmabuf array use kvmalloc_array, this can fallback alloc into vmalloc, which can guarantee allocation for any size and does not affect the performance of kmalloc allocations. | ["https://git.kernel.org/stable/c/1c0844c6184e658064e14c4335885785ad3bf84b","https://git.kernel.org/stable/c/2acc6192aa8570661ed37868c02c03002b1dc290","https://git.kernel.org/stable/c/85bb72397cb63649fe493c96e27e1d0e4ed2ff63"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48982 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix crash when replugging CSR fake controllers It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic: [ 71.986122] Call Trace: [ 71.986124] <TASK> [ 71.986125] blocking_notifier_chain_register+0x33/0x60 [ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300 [ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90 [ 71.986167] usb_probe_interface+0xe3/0x2b0 [ 71.986171] really_probe+0xdb/0x380 [ 71.986174] ? pm_runtime_barrier+0x54/0x90 [ 71.986177] __driver_probe_device+0x78/0x170 [ 71.986180] driver_probe_device+0x1f/0x90 [ 71.986183] __device_attach_driver+0x89/0x110 [ 71.986186] ? driver_allows_async_probing+0x70/0x70 [ 71.986189] bus_for_each_drv+0x8c/0xe0 [ 71.986192] __device_attach+0xb2/0x1e0 [ 71.986195] bus_probe_device+0x92/0xb0 [ 71.986198] device_add+0x422/0x9a0 [ 71.986201] ? sysfs_merge_group+0xd4/0x110 [ 71.986205] usb_set_configuration+0x57a/0x820 [ 71.986208] usb_generic_driver_probe+0x4f/0x70 [ 71.986211] usb_probe_device+0x3a/0x110 [ 71.986213] really_probe+0xdb/0x380 [ 71.986216] ? pm_runtime_barrier+0x54/0x90 [ 71.986219] __driver_probe_device+0x78/0x170 [ 71.986221] driver_probe_device+0x1f/0x90 [ 71.986224] __device_attach_driver+0x89/0x110 [ 71.986227] ? driver_allows_async_probing+0x70/0x70 [ 71.986230] bus_for_each_drv+0x8c/0xe0 [ 71.986232] __device_attach+0xb2/0x1e0 [ 71.986235] bus_probe_device+0x92/0xb0 [ 71.986237] device_add+0x422/0x9a0 [ 71.986239] ? _dev_info+0x7d/0x98 [ 71.986242] ? blake2s_update+0x4c/0xc0 [ 71.986246] usb_new_device.cold+0x148/0x36d [ 71.986250] hub_event+0xa8a/0x1910 [ 71.986255] process_one_work+0x1c4/0x380 [ 71.986259] worker_thread+0x51/0x390 [ 71.986262] ? rescuer_thread+0x3b0/0x3b0 [ 71.986264] kthread+0xdb/0x110 [ 71.986266] ? kthread_complete_and_exit+0x20/0x20 [ 71.986268] ret_from_fork+0x1f/0x30 [ 71.986273] </TASK> [ 71.986274] ---[ end trace 0000000000000000 ]--- [ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17 | ["https://git.kernel.org/stable/c/549b46f8130effccf168293270bb3b1d5da529cc","https://git.kernel.org/stable/c/a49894a5ac3656f1a4f0f6b110460060e8026bf8","https://git.kernel.org/stable/c/b5ca338751ad4783ec8d37b5d99c3e37b7813e59","https://git.kernel.org/stable/c/dc8fa6570deadb70c3fb74d7cd8ce38849feaed0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50108 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too Stuart Hayhurst has found that both at bootup and fullscreen VA-API video is leading to black screens for around 1 second and kernel WARNING [1] traces when calling dmub_psr_enable() with Parade 08-01 TCON. These symptoms all go away with PSR-SU disabled for this TCON, so disable it for now while DMUB traces [2] from the failure can be analyzed and the failure state properly root caused. (cherry picked from commit afb634a6823d8d9db23c5fb04f79c5549349628b) | ["https://git.kernel.org/stable/c/5660bcc4dd533005248577d5042f1c48cce2b443","https://git.kernel.org/stable/c/ba1959f71117b27f3099ee789e0815360b4081dd","https://git.kernel.org/stable/c/c79e0a18e4b301401bb745702830be9041cfbf04","https://git.kernel.org/stable/c/fc6afa07b5e251148fb37600ee06e1a7007178c3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57807 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. | ["https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554","https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8","https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7","https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b","https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d","https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815","https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22063 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets When calling netlbl_conn_setattr(), addr->sa_family is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipso_sock_setattr() is triggered. Inside this function, the following code is executed: sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL; Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference. This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6. | ["https://git.kernel.org/stable/c/078aabd567de3d63d37d7673f714e309d369e6e2","https://git.kernel.org/stable/c/172a8a996a337206970467e871dd995ac07640b1","https://git.kernel.org/stable/c/1927d0bcd5b81e80971bf6b8eba267508bd1c78b","https://git.kernel.org/stable/c/1ad9166cab6a0f5c0b10344a97bdf749ae11dcbf","https://git.kernel.org/stable/c/1e38f7a6cdd68377f8a4189b2fbaec14a6dd5152","https://git.kernel.org/stable/c/3ba9cf69de50e8abed32b448616c313baa4c5712","https://git.kernel.org/stable/c/797e5371cf55463b4530bab3fef5f27f7c6657a8","https://git.kernel.org/stable/c/9fe3839588db7519030377b7dee3f165e654f6c5","https://git.kernel.org/stable/c/a7e89541d05b98c79a51c0f95df020f8e82b62ed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-23136 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal: int340x: Add NULL check for adev Not all devices have an ACPI companion fwnode, so adev might be NULL. This is similar to the commit cd2fd6eab480 ("platform/x86: int3472: Check for adev == NULL"). Add a check for adev not being set and return -ENODEV in that case to avoid a possible NULL pointer deref in int3402_thermal_probe(). Note, under the same directory, int3400_thermal_probe() has such a check. [ rjw: Subject edit, added Fixes: ] | ["https://git.kernel.org/stable/c/0c49f12c77b77a706fd41370c11910635e491845","https://git.kernel.org/stable/c/2542a3f70e563a9e70e7ded314286535a3321bdb","https://git.kernel.org/stable/c/3155d5261b518776d1b807d9d922669991bbee56","https://git.kernel.org/stable/c/6a810c462f099353e908c70619638884cb82229c","https://git.kernel.org/stable/c/8e8f1ddf4186731649df8bc9646017369eb19186","https://git.kernel.org/stable/c/953d28a4f459fcbde2d08f51aeca19d6b0f179f3","https://git.kernel.org/stable/c/ac2eb7378319e3836cdf3a2c15a0bdf04c50e81d","https://git.kernel.org/stable/c/bc7b5f782d28942dbdfda70df30ce132694a06de","https://git.kernel.org/stable/c/d0d21c8e44216fa9afdb3809edf213f3c0a8c060"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46777 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid excessive partition lengths Avoid mounting filesystems where the partition would overflow the 32-bits used for block number. Also refuse to mount filesystems where the partition length is so large we cannot safely index bits in a block bitmap. | ["https://git.kernel.org/stable/c/0173999123082280cf904bd640015951f194a294","https://git.kernel.org/stable/c/1497a4484cdb2cf6c37960d788fb6ba67567bdb7","https://git.kernel.org/stable/c/2ddf831451357c6da4b64645eb797c93c1c054d1","https://git.kernel.org/stable/c/551966371e17912564bc387fbeb2ac13077c3db1","https://git.kernel.org/stable/c/925fd8ee80d5348a5e965548e5484d164d19221d","https://git.kernel.org/stable/c/a56330761950cb83de1dfb348479f20c56c95f90","https://git.kernel.org/stable/c/c0c23130d38e8bc28e9ef581443de9b1fc749966","https://git.kernel.org/stable/c/ebbe26fd54a9621994bc16b14f2ba8f84c089693"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53221 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix null-ptr-deref in f2fs_submit_page_bio() There's issue as follows when concurrently installing the f2fs.ko module and mounting the f2fs file system: KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs] Call Trace: <TASK> f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Above issue happens as the biset of the f2fs file system is not initialized before register "f2fs_fs_type". To address above issue just register "f2fs_fs_type" at the last in init_f2fs_fs(). Ensure that all f2fs file system resources are initialized. | ["https://git.kernel.org/stable/c/32f5e291b7677495f98246eec573767430321c08","https://git.kernel.org/stable/c/8dddc12d03248755d9f709bc1eb9e3ea2bf1b322","https://git.kernel.org/stable/c/9e11b1d5fda972f6be60ab732976a7c8e064cd56","https://git.kernel.org/stable/c/b7d0a97b28083084ebdd8e5c6bccd12e6ec18faa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33744 | Medium | N/A | Arm guests can cause Dom0 DoS via PV devices When mapping pages of guests on Arm, dom0 is using an rbtree to keep track of the foreign mappings. Updating of that rbtree is not always done completely with the related lock held, resulting in a small race window, which can be used by unprivileged guests via PV devices to cause inconsistencies of the rbtree. These inconsistencies can lead to Denial of Service (DoS) of dom0, e.g. by causing crashes or the inability to perform further mappings of other guests' memory pages. | ["http://www.openwall.com/lists/oss-security/2022/07/05/4","http://xenbits.xen.org/xsa/advisory-406.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-406.txt","http://www.openwall.com/lists/oss-security/2022/07/05/4","http://xenbits.xen.org/xsa/advisory-406.html","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://www.debian.org/security/2022/dsa-5191","https://xenbits.xenproject.org/xsa/advisory-406.txt"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1206 | Medium | fixed |
|
A hash collision flaw was found in the IPv6 connection lookup table in the Linux kernel’s IPv6 functionality when a user makes a new kind of SYN flood attack. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2175903","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://bugzilla.redhat.com/show_bug.cgi?id=2175903","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0006/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56748 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb() Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). | ["https://git.kernel.org/stable/c/0e04bd5a11dffe8c1c0e4c9fc79f7d3cd6182dd5","https://git.kernel.org/stable/c/64654bf5efb3f748e6fc41227adda689618ce9c4","https://git.kernel.org/stable/c/78a169dc69fbdaf114c40e2d56955bf6bd4fc3c0","https://git.kernel.org/stable/c/7c1832287b21ff68c4e3625e63cc7619edf5908b","https://git.kernel.org/stable/c/97384449ddfc07f12ca75f510eb070020d7abb34","https://git.kernel.org/stable/c/a56777a3ef5b35e24a20c4418bcf88bad033807a","https://git.kernel.org/stable/c/b514f45e0fe18d763a1afc34401b1585333cb329","https://git.kernel.org/stable/c/c62c30429db3eb4ced35c7fcf6f04a61ce3a01bb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53052 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user. | ["https://git.kernel.org/stable/c/003d2996964c03dfd34860500428f4cdf1f5879e","https://git.kernel.org/stable/c/1d60d74e852647255bd8e76f5a22dc42531e4389","https://git.kernel.org/stable/c/26b8c48f369b7591f5679e0b90612f4862a32929","https://git.kernel.org/stable/c/485d9232112b17f389b29497ff41b97b3189546b","https://git.kernel.org/stable/c/4e24041ba86d50aaa4c792ae2c88ed01b3d96243","https://git.kernel.org/stable/c/9e8debb8e51354b201db494689198078ec2c1e75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56627 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Out-of-Bounds Read in ksmbd_vfs_stream_read An offset from client could be a negative value, It could lead to an out-of-bounds read from the stream_buf. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. | ["https://git.kernel.org/stable/c/27de4295522e9a33e4a3fc72f7b8193df9eebe41","https://git.kernel.org/stable/c/6bd1bf0e8c42f10a9a9679a4c103a9032d30594d","https://git.kernel.org/stable/c/81eed631935f2c52cdaf6691c6d48e0b06e8ad73","https://git.kernel.org/stable/c/de4d790dcf53be41736239d7ee63849a16ff5d10","https://git.kernel.org/stable/c/fc342cf86e2dc4d2edb0fc2ff5e28b6c7845adb9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-37785 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix OOB read when checking dotdot dir Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed). ext4_empty_dir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4_check_dir_entry() and then uses its rec_len member to compute the location of '..' dir entry (in ext4_next_entry). It assumes the '..' dir entry fits into the same data block. If the rec_len of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4_dir_entry_2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4_check_dir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access. Fix this by extending __ext4_check_dir_entry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero). Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read. This issue was found by syzkaller tool. Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in __ext4_check_dir_entry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dump_stack_lvl+0xa7/0xd0 [ 38.595325] print_address_description.constprop.0+0x2c/0x3f0 [ 38.595339] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595349] print_report+0xaa/0x250 [ 38.595359] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595368] ? kasan_addr_to_slab+0x9/0x90 [ 38.595378] kasan_report+0xab/0xe0 [ 38.595389] ? __ext4_check_dir_entry+0x67e/0x710 [ 38.595400] __ext4_check_dir_entry+0x67e/0x710 [ 38.595410] ext4_empty_dir+0x465/0x990 [ 38.595421] ? __pfx_ext4_empty_dir+0x10/0x10 [ 38.595432] ext4_rmdir.part.0+0x29a/0xd10 [ 38.595441] ? __dquot_initialize+0x2a7/0xbf0 [ 38.595455] ? __pfx_ext4_rmdir.part.0+0x10/0x10 [ 38.595464] ? __pfx___dquot_initialize+0x10/0x10 [ 38.595478] ? down_write+0xdb/0x140 [ 38.595487] ? __pfx_down_write+0x10/0x10 [ 38.595497] ext4_rmdir+0xee/0x140 [ 38.595506] vfs_rmdir+0x209/0x670 [ 38.595517] ? lookup_one_qstr_excl+0x3b/0x190 [ 38.595529] do_rmdir+0x363/0x3c0 [ 38.595537] ? __pfx_do_rmdir+0x10/0x10 [ 38.595544] ? strncpy_from_user+0x1ff/0x2e0 [ 38.595561] __x64_sys_unlinkat+0xf0/0x130 [ 38.595570] do_syscall_64+0x5b/0x180 [ 38.595583] entry_SYSCALL_64_after_hwframe+0x76/0x7e | ["https://git.kernel.org/stable/c/14da7dbecb430e35b5889da8dae7bef33173b351","https://git.kernel.org/stable/c/52a5509ab19a5d3afe301165d9b5787bba34d842","https://git.kernel.org/stable/c/53bc45da8d8da92ec07877f5922b130562eb4b00","https://git.kernel.org/stable/c/89503e5eae64637d0fa2218912b54660effe7d93","https://git.kernel.org/stable/c/ac28c5684c1cdab650a7e5065b19e91577d37a4b","https://git.kernel.org/stable/c/b47584c556444cf7acb66b26a62cbc348eb92b78","https://git.kernel.org/stable/c/b7531a4f99c3887439d778afaf418d1a01a5f01b","https://git.kernel.org/stable/c/d5e206778e96e8667d3bde695ad372c296dc9353","https://git.kernel.org/stable/c/e47f472a664d70a3d104a6c2a035cdff55a719b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47738 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 | ["https://git.kernel.org/stable/c/3565ef215101ffadb5fe5394c70b1fca51376b25","https://git.kernel.org/stable/c/43897111481b679508711d3ca881c4c6593e9247","https://git.kernel.org/stable/c/aafca50e71dc8f3192a5bfb325135a7908f3ef9e","https://git.kernel.org/stable/c/d54455a3a965feb547711aff7afd2ca5deadb99c","https://git.kernel.org/stable/c/e7a7ef9a0742dbd0818d5b15fba2c5313ace765b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4389 | High | fixed |
|
A flaw was found in btrfs_get_root_ref in fs/btrfs/disk-io.c in the btrfs filesystem in the Linux Kernel due to a double decrement of the reference count. This issue may allow a local attacker with user privilege to crash the system or may lead to leaked internal kernel information. | ["https://access.redhat.com/security/cve/CVE-2023-4389","https://bugzilla.redhat.com/show_bug.cgi?id=2219271","https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-4389","https://bugzilla.redhat.com/show_bug.cgi?id=2219271","https://patchwork.kernel.org/project/linux-btrfs/patch/20220324134454.15192-1-baijiaju1990@gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50135 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix race condition between reset and nvme_dev_disable() nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: <TASK> ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme] Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already. | ["https://git.kernel.org/stable/c/26bc0a81f64ce00fc4342c38eeb2eddaad084dd2","https://git.kernel.org/stable/c/4ed32cc0939b64e3d7b48c8c0d63ea038775f304","https://git.kernel.org/stable/c/b33e49a5f254474b33ce98fd45dd0ffdc247a0be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46787 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: userfaultfd: fix checks for huge PMDs Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2. The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version: 1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong. I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2. This patch (of 2): This fixes two issues. I discovered that the following race can occur: mfill_atomic other thread ============ ============ <zap PMD> pmdp_get_lockless() [reads none pmd] <bail if trans_huge> <if none:> <pagefault creates transhuge zeropage> __pte_alloc [no-op] <zap PMD> <bail if pmd_trans_huge(*dst_pmd)> BUG_ON(pmd_none(*dst_pmd)) I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers. On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table. The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs). On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table. Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different). If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table. As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway. Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels. | ["https://git.kernel.org/stable/c/3c6b4bcf37845c9359aed926324bed66bdd2448d","https://git.kernel.org/stable/c/71c186efc1b2cf1aeabfeff3b9bd5ac4c5ac14d8","https://git.kernel.org/stable/c/98cc18b1b71e23fe81a5194ed432b20c2d81a01a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50277 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement "md->disk->private_data = NULL;". | ["https://git.kernel.org/stable/c/d7aec2a06730b774a97caaf48cbbc58330a85829","https://git.kernel.org/stable/c/fed13a5478680614ba97fc87e71f16e2e197912e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53100 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated--- | ["https://git.kernel.org/stable/c/4f946479b326a3cbb193f2b8368aed9269514c35","https://git.kernel.org/stable/c/782373ba27660ba7d330208cf5509ece6feb4545","https://git.kernel.org/stable/c/975cb1d2121511584695d0e47fdb90e6782da007","https://git.kernel.org/stable/c/e15cebc1b21856944b387f4abd03b66bd3d4f027"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3028 | High | fixed |
|
A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrm_probe_algs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket. | ["https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/","https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/","https://security.netapp.com/advisory/ntap-20230214-0004/","https://github.com/torvalds/linux/commit/ba953a9d89a00c078b85f4b190bc1dde66fe16b5","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/F3MYP7WX4PNE6RCITVXA43CECBZT4CL6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JKVA75UHKVOHNOEPCLUHTFGWCOOUBDM3/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/PEQYVCNYUWB4CJ2YRAYNF2GGFQ7SUYC4/","https://lore.kernel.org/all/YtoWqEkKzvimzWS5%40gondor.apana.org.au/T/","https://security.netapp.com/advisory/ntap-20230214-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-28466 | High | fixed |
|
do_tls_getsockopt in net/tls/tls_main.c in the Linux kernel through 6.2.6 lacks a lock_sock call, leading to a race condition (with a resultant use-after-free or NULL pointer dereference). | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230427-0006/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=49c47cc21b5b7a3d8deb18fc57b0aa2ab1286962","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://security.netapp.com/advisory/ntap-20230427-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47141 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinmux: Use sequential access to access desc->pinmux data When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner. Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer. Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B) pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } } | ["https://git.kernel.org/stable/c/2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b","https://git.kernel.org/stable/c/5a3e85c3c397c781393ea5fb2f45b1f60f8a4e6e","https://git.kernel.org/stable/c/c11e2ec9a780f54982a187ee10ffd1b810715c85"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-48875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't take dev_replace rwsem on task already holding it Running fstests btrfs/011 with MKFS_OPTIONS="-O rst" to force the usage of the RAID stripe-tree, we get the following splat from lockdep: BTRFS info (device sdd): dev_replace from /dev/sdd (devid 1) to /dev/sdb started ============================================ WARNING: possible recursive locking detected 6.11.0-rc3-btrfs-for-next #599 Not tainted -------------------------------------------- btrfs/2326 is trying to acquire lock: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250 but task is already holding lock: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&fs_info->dev_replace.rwsem); lock(&fs_info->dev_replace.rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by btrfs/2326: #0: ffff88810f215c98 (&fs_info->dev_replace.rwsem){++++}-{3:3}, at: btrfs_map_block+0x39f/0x2250 stack backtrace: CPU: 1 UID: 0 PID: 2326 Comm: btrfs Not tainted 6.11.0-rc3-btrfs-for-next #599 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dump_stack_lvl+0x5b/0x80 __lock_acquire+0x2798/0x69d0 ? __pfx___lock_acquire+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 lock_acquire+0x19d/0x4a0 ? btrfs_map_block+0x39f/0x2250 ? __pfx_lock_acquire+0x10/0x10 ? find_held_lock+0x2d/0x110 ? lock_is_held_type+0x8f/0x100 down_read+0x8e/0x440 ? btrfs_map_block+0x39f/0x2250 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 btrfs_map_block+0x39f/0x2250 ? btrfs_dev_replace_by_ioctl+0xd69/0x1d00 ? btrfs_bio_counter_inc_blocked+0xd9/0x2e0 ? __kasan_slab_alloc+0x6e/0x70 ? __pfx_btrfs_map_block+0x10/0x10 ? __pfx_btrfs_bio_counter_inc_blocked+0x10/0x10 ? kmem_cache_alloc_noprof+0x1f2/0x300 ? mempool_alloc_noprof+0xed/0x2b0 btrfs_submit_chunk+0x28d/0x17e0 ? __pfx_btrfs_submit_chunk+0x10/0x10 ? bvec_alloc+0xd7/0x1b0 ? bio_add_folio+0x171/0x270 ? __pfx_bio_add_folio+0x10/0x10 ? __kasan_check_read+0x20/0x20 btrfs_submit_bio+0x37/0x80 read_extent_buffer_pages+0x3df/0x6c0 btrfs_read_extent_buffer+0x13e/0x5f0 read_tree_block+0x81/0xe0 read_block_for_search+0x4bd/0x7a0 ? __pfx_read_block_for_search+0x10/0x10 btrfs_search_slot+0x78d/0x2720 ? __pfx_btrfs_search_slot+0x10/0x10 ? lock_is_held_type+0x8f/0x100 ? kasan_save_track+0x14/0x30 ? __kasan_slab_alloc+0x6e/0x70 ? kmem_cache_alloc_noprof+0x1f2/0x300 btrfs_get_raid_extent_offset+0x181/0x820 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_btrfs_get_raid_extent_offset+0x10/0x10 ? down_read+0x194/0x440 ? __pfx_down_read+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 btrfs_map_block+0x5b5/0x2250 ? __pfx_btrfs_map_block+0x10/0x10 scrub_submit_initial_read+0x8fe/0x11b0 ? __pfx_scrub_submit_initial_read+0x10/0x10 submit_initial_group_read+0x161/0x3a0 ? lock_release+0x20e/0x710 ? __pfx_submit_initial_group_read+0x10/0x10 ? __pfx_lock_release+0x10/0x10 scrub_simple_mirror.isra.0+0x3eb/0x580 scrub_stripe+0xe4d/0x1440 ? lock_release+0x20e/0x710 ? __pfx_scrub_stripe+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? do_raw_read_unlock+0x44/0x70 ? _raw_read_unlock+0x23/0x40 scrub_chunk+0x257/0x4a0 scrub_enumerate_chunks+0x64c/0xf70 ? __mutex_unlock_slowpath+0x147/0x5f0 ? __pfx_scrub_enumerate_chunks+0x10/0x10 ? bit_wait_timeout+0xb0/0x170 ? __up_read+0x189/0x700 ? scrub_workers_get+0x231/0x300 ? up_write+0x490/0x4f0 btrfs_scrub_dev+0x52e/0xcd0 ? create_pending_snapshots+0x230/0x250 ? __pfx_btrfs_scrub_dev+0x10/0x10 btrfs_dev_replace_by_ioctl+0xd69/0x1d00 ? lock_acquire+0x19d/0x4a0 ? __pfx_btrfs_dev_replace_by_ioctl+0x10/0x10 ? ---truncated--- | ["https://git.kernel.org/stable/c/8cca35cb29f81eba3e96ec44dad8696c8a2f9138","https://git.kernel.org/stable/c/a2e99dcd7aafa9d474f7d9b0740b8f93c4e156c2","https://git.kernel.org/stable/c/a5bc4e030f50fdbb1fbc69acc1e0c5f57c79d044"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-54683 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown. | ["https://git.kernel.org/stable/c/45fe76573a2557f632e248cc141342233f422b9a","https://git.kernel.org/stable/c/8c2c8445cda8f59c38dec7dc10509bcb23ae26a0","https://git.kernel.org/stable/c/f36b01994d68ffc253c8296e2228dfe6e6431c03"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58012 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps. | ["https://git.kernel.org/stable/c/569922b82ca660f8b24e705f6cf674e6b1f99cc7","https://git.kernel.org/stable/c/789a2fbf0900982788408d3b0034e0e3f914fb3b","https://git.kernel.org/stable/c/e012a77e4d7632cf615ba9625b1600ed8985c3b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48992 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: soc-pcm: Add NULL check in BE reparenting Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test. | ["https://git.kernel.org/stable/c/0760acc2e6598ad4f7bd3662db2d907ef0838139","https://git.kernel.org/stable/c/34a9796bf0684bfd54e96a142560d560c21c983b","https://git.kernel.org/stable/c/9f74b9aa8d58c18927bb9b65dd5ba70a5fd61615","https://git.kernel.org/stable/c/d4dd21a79dbb862d2ebcf9ed90e646416009ff0d","https://git.kernel.org/stable/c/db8f91d424fe0ea6db337aca8bc05908bbce1498","https://git.kernel.org/stable/c/e7166d6821c15f3516bcac8ae3f155924da1908c","https://git.kernel.org/stable/c/f2ba66d8738584d124aff4e760ed1337f5f6dfb6","https://git.kernel.org/stable/c/f6f45e538328df9ce66aa61bafee1a5717c4b700"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48994 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: seq: Fix function prototype mismatch in snd_seq_expand_var_event With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. seq_copy_in_user() and seq_copy_in_kernel() did not have prototypes matching snd_seq_dump_func_t. Adjust this and remove the casts. There are not resulting binary output differences. This was found as a result of Clang's new -Wcast-function-type-strict flag, which is more sensitive than the simpler -Wcast-function-type, which only checks for type width mismatches. | ["https://git.kernel.org/stable/c/05530ef7cf7c7d700f6753f058999b1b5099a026","https://git.kernel.org/stable/c/13ee8fb5410b740c8dd2867d3557c7662f7dda2d","https://git.kernel.org/stable/c/15c42ab8d43acb73e2eba361ad05822c0af0ecfa","https://git.kernel.org/stable/c/2f46e95bf344abc4e74f8158901d32a869e0adb6","https://git.kernel.org/stable/c/63badfed200219ca656968725f1a43df293ac936","https://git.kernel.org/stable/c/b38486e82ecb9f3046e0184205f6b61408fc40c9","https://git.kernel.org/stable/c/e385360705a0b346bdb57ce938249175d0613b8a","https://git.kernel.org/stable/c/fccd454129f6a0739651f7f58307cdb631fd6e89"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-52559 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit() The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32 values that come from the user via the submit_lookup_cmds() function. This addition could lead to an integer wrapping bug so use size_add() to prevent that. Patchwork: https://patchwork.freedesktop.org/patch/624696/ | ["https://git.kernel.org/stable/c/2b99b2c4621d13bd4374ef384e8f1fc188d0a5df","https://git.kernel.org/stable/c/2f1845e46c41ed500789d53dc45b383b7745c96c","https://git.kernel.org/stable/c/3a47f4b439beb98e955d501c609dfd12b7836d61","https://git.kernel.org/stable/c/e43a0f1327a1ee70754f8a0de6e0262cfa3e0b87"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21941 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_params Null pointer dereference issue could occur when pipe_ctx->plane_state is null. The fix adds a check to ensure 'pipe_ctx->plane_state' is not null before accessing. This prevents a null pointer dereference. Found by code review. (cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092) | ["https://git.kernel.org/stable/c/265422915416468ba91bffa56addbff45e18342a","https://git.kernel.org/stable/c/3748fad09d89e9a5290e1738fd6872a79f794743","https://git.kernel.org/stable/c/374c9faac5a763a05bc3f68ad9f73dab3c6aec90","https://git.kernel.org/stable/c/3b3c2be58d5275aa59d8b4810a59f173f2f5bac1","https://git.kernel.org/stable/c/c1e54752dc12e90305eb0475ca908f42f5b369ca","https://git.kernel.org/stable/c/e0345c3478f185ca840daac7f08a1fcd4ebec3e9","https://git.kernel.org/stable/c/f435192e00bc4d5d4134356b93212670ec47fa8d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21963 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing acdirmax mount option User-provided mount parameter acdirmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0c26edf477e093cefc41637f5bccc102e1a77399","https://git.kernel.org/stable/c/2809a79bc64964ce02e0c5f2d6bd39b9d09bdb3c","https://git.kernel.org/stable/c/39d086bb3558da9640ef335f97453e01d32578a1","https://git.kernel.org/stable/c/5b29891f91dfb8758baf1e2217bef4b16b2b165b","https://git.kernel.org/stable/c/6124cbf73e3dea7591857dd63b8ccece28952afd","https://git.kernel.org/stable/c/9e438d0410a4002d24f420f2c28897ba2dc0af64"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21964 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix integer overflow while processing acregmax mount option User-provided mount parameter acregmax of type u32 is intended to have an upper limit, but before it is validated, the value is converted from seconds to jiffies which can lead to an integer overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/0252c33cc943e9e48ddfafaa6b1eb72adb68a099","https://git.kernel.org/stable/c/5f500874ab9b3cc8c169c2ab49f00b838520b9c5","https://git.kernel.org/stable/c/7489161b1852390b4413d57f2457cd40b34da6cc","https://git.kernel.org/stable/c/833f2903eb8b70faca7967319e580e9ce69729fc","https://git.kernel.org/stable/c/a13351624a6af8d91398860b8c9d4cf6c8e63de5","https://git.kernel.org/stable/c/dd190168e60ac15408f074a1fe0ce36aff34027b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21981 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: fix memory leak in aRFS after reset Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... | ["https://git.kernel.org/stable/c/23d97f18901ef5e4e264e3b1777fe65c760186b5","https://git.kernel.org/stable/c/3b27e6e10a32589fcd293b8933ab6de9387a460e","https://git.kernel.org/stable/c/5d30d256661fc11b6e73fac6c3783a702e1006a3","https://git.kernel.org/stable/c/78f3d64b30210c0e521c59357431aca14024cb79","https://git.kernel.org/stable/c/e6902101f34f098af59b0d1d8cf90c4124c02c6a","https://git.kernel.org/stable/c/ef2bc94059836a115430a6ad9d2838b0b34dc8f5","https://git.kernel.org/stable/c/fcbacc47d16306c87ad1b820b7a575f6e9eae58b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53157 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scpi: Check the DVFS OPP count returned by the firmware Fix a kernel crash with the below call trace when the SCPI firmware returns OPP count of zero. dvfs_info.opp_count may be zero on some platforms during the reboot test, and the kernel will crash after dereferencing the pointer to kcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none | ["https://git.kernel.org/stable/c/025067eeb945aa17c7dd483a63960125b7efb577","https://git.kernel.org/stable/c/06258e57fee253f4046d3a6a86d7fde09f596eac","https://git.kernel.org/stable/c/109aa654f85c5141e813b2cd1bd36d90be678407","https://git.kernel.org/stable/c/12e2c520a0a4202575e4a45ea41f06a8e9aa3417","https://git.kernel.org/stable/c/2a5b8de6fcb944f9af0c5fcb30bb0c039705e051","https://git.kernel.org/stable/c/380c0e1d96f3b522f3170c18ee5e0f1a28fec5d6","https://git.kernel.org/stable/c/8be4e51f3ecfb0915e3510b600c4cce0dc68a383","https://git.kernel.org/stable/c/9beaff47bcea5eec7d4ead98f5043057161fd71a","https://git.kernel.org/stable/c/dfc9c2aa7f04f7db7e7225a5e118a24bf1c3b325"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53217 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: Prevent NULL dereference in nfsd4_process_cb_update() @ses is initialized to NULL. If __nfsd4_find_backchannel() finds no available backchannel session, setup_callback_client() will try to dereference @ses and segfault. | ["https://git.kernel.org/stable/c/03178cd8f67227015debb700123987fe96275cd1","https://git.kernel.org/stable/c/0c3b0e326f838787d229314d4de83af9c53347e8","https://git.kernel.org/stable/c/1e02c641c3a43c88cecc08402000418e15578d38","https://git.kernel.org/stable/c/4a4ffc1aa9d618e41ad9151f40966e402e58a5a2","https://git.kernel.org/stable/c/752a75811f27300fe8131b0a1efc91960f6f88e7","https://git.kernel.org/stable/c/c5d90f9302742985a5078e42ac38de42c364c44a","https://git.kernel.org/stable/c/cac1405e3ff6685a438e910ad719e0cf06af90ee","https://git.kernel.org/stable/c/d9a0d1f6e15859ea7a86a327f28491e23deaaa62","https://git.kernel.org/stable/c/eb51733ae5fc73d95bd857d5da26f9f65b202a79"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21891 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipvlan: ensure network headers are in skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1] BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline] | ["https://git.kernel.org/stable/c/27843ce6ba3d3122b65066550fe33fb8839f8aef","https://git.kernel.org/stable/c/4ec48f812804f370f622e0874e6dd8fcc58241cd","https://git.kernel.org/stable/c/5353fd89663c48f56bdff975c562cfe78b1a2e4c","https://git.kernel.org/stable/c/5b8dea8d1612dc7151d2457d7d2e6a69820309bf","https://git.kernel.org/stable/c/e2a4f76a2d8a44816ecd25bcbdb47b786d621974"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50298 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8 | ["https://git.kernel.org/stable/c/7eb923f8d4819737c07d6a8d0daef0a4d7f99e0c","https://git.kernel.org/stable/c/e15c5506dd39885cd047f811a64240e2e8ab401b","https://git.kernel.org/stable/c/ef0edfbe9eeed1fccad7cb705648af5222664944"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53091 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes | ["https://git.kernel.org/stable/c/44d0469f79bd3d0b3433732877358df7dc6b17b1","https://git.kernel.org/stable/c/6781cfa93a6a1b7f5be6819a5a2dd8f30f47ca26","https://git.kernel.org/stable/c/a078a480ff3f43d74d8a024ae10c3c7daf6db149"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-35978 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix memory leak in hci_req_sync_complete() In 'hci_req_sync_complete()', always free the previous sync request state before assigning reference to a new one. | ["https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810","https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2","https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8","https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06","https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0","https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67","https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76","https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5","https://git.kernel.org/stable/c/45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810","https://git.kernel.org/stable/c/4beab84fbb50df3be1d8f8a976e6fe882ca65cb2","https://git.kernel.org/stable/c/66fab1e120b39f8f47a94186ddee36006fc02ca8","https://git.kernel.org/stable/c/75193678cce993aa959e7764b6df2f599886dd06","https://git.kernel.org/stable/c/8478394f76c748862ef179a16f651f752bdafaf0","https://git.kernel.org/stable/c/89a32741f4217856066c198a4a7267bcdd1edd67","https://git.kernel.org/stable/c/9ab5e44b9bac946bd49fd63264a08cd1ea494e76","https://git.kernel.org/stable/c/e4cb8382fff6706436b66eafd9c0ee857ff0a9f5","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3611 | High | fixed |
|
An out-of-bounds write vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation. The qfq_change_agg() function in net/sched/sch_qfq.c allows an out-of-bounds write because lmax is updated according to packet sizes without bounds checks. We recommend upgrading past commit 3e337087c3b5805fe0b8a46ba622a962880b5d64. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64","https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230908-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e337087c3b5805fe0b8a46ba622a962880b5d64","https://kernel.dance/3e337087c3b5805fe0b8a46ba622a962880b5d64","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230908-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49840 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line. | ["https://git.kernel.org/stable/c/047824a730699c6c66df43306b80f700c9dfc2fd","https://git.kernel.org/stable/c/1b597f2d6a55e9f549989913860ad5170da04964","https://git.kernel.org/stable/c/730fb1ef974a13915bc7651364d8b3318891cd70","https://git.kernel.org/stable/c/7a704dbfd3735304e261f2787c52fbc7c3884736","https://git.kernel.org/stable/c/d3fd203f36d46aa29600a72d57a1b61af80e4a25","https://git.kernel.org/stable/c/e60f37a1d379c821c17b08f366412dce9ef3d99f","https://git.kernel.org/stable/c/eaa8edd86514afac9deb9bf9a5053e74f37edf40"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49842 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: core: Fix use-after-free in snd_soc_exit() KASAN reports a use-after-free: BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK> It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. | ["https://git.kernel.org/stable/c/2ec3f558db343b045a7c7419cdbaec266b8ac1a7","https://git.kernel.org/stable/c/34eee4189bcebbd5f6a2ff25ef0cb893ad33d51e","https://git.kernel.org/stable/c/41fad4f712e081acdfde8b59847f9f66eaf407a0","https://git.kernel.org/stable/c/6ec27c53886c8963729885bcf2dd996eba2767a7","https://git.kernel.org/stable/c/8d21554ec7680e9585fb852d933203c3db60dad1","https://git.kernel.org/stable/c/90bbdf30a51e42378cb23a312005a022794b8e1e","https://git.kernel.org/stable/c/a3365e62239dc064019a244bde5686ac18527c22","https://git.kernel.org/stable/c/c5674bd073c0fd9f620ca550c5ff08d0d429bdd9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49846 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udf: Fix a slab-out-of-bounds write bug in udf_find_entry() Syzbot reported a slab-out-of-bounds Write bug: loop0: detected capacity change from 0 to 2048 ================================================================== BUG: KASAN: slab-out-of-bounds in udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 Write of size 105 at addr ffff8880123ff896 by task syz-executor323/3610 CPU: 0 PID: 3610 Comm: syz-executor323 Not tainted 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 kasan_check_range+0x2a7/0x2e0 mm/kasan/generic.c:189 memcpy+0x3c/0x60 mm/kasan/shadow.c:66 udf_find_entry+0x8a5/0x14f0 fs/udf/namei.c:253 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7ffab0d164d9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe1a7e6bb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000055 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffab0d164d9 RDX: 00007ffab0d164d9 RSI: 0000000000000000 RDI: 0000000020000180 RBP: 00007ffab0cd5a10 R08: 0000000000000000 R09: 0000000000000000 R10: 00005555573552c0 R11: 0000000000000246 R12: 00007ffab0cd5aa0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK> Allocated by task 3610: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:576 [inline] udf_find_entry+0x7b6/0x14f0 fs/udf/namei.c:243 udf_lookup+0xef/0x340 fs/udf/namei.c:309 lookup_open fs/namei.c:3391 [inline] open_last_lookups fs/namei.c:3481 [inline] path_openat+0x10e6/0x2df0 fs/namei.c:3710 do_filp_open+0x264/0x4f0 fs/namei.c:3740 do_sys_openat2+0x124/0x4e0 fs/open.c:1310 do_sys_open fs/open.c:1326 [inline] __do_sys_creat fs/open.c:1402 [inline] __se_sys_creat fs/open.c:1396 [inline] __x64_sys_creat+0x11f/0x160 fs/open.c:1396 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd The buggy address belongs to the object at ffff8880123ff800 which belongs to the cache kmalloc-256 of size 256 The buggy address is located 150 bytes inside of 256-byte region [ffff8880123ff800, ffff8880123ff900) The buggy address belongs to the physical page: page:ffffea000048ff80 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x123fe head:ffffea000048ff80 order:1 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 ffffea00004b8500 dead000000000003 ffff888012041b40 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x0(), pid 1, tgid 1 (swapper/0), ts 1841222404, free_ts 0 create_dummy_stack mm/page_owner.c: ---truncated--- | ["https://git.kernel.org/stable/c/03f9582a6a2ebd25a440896475c968428c4b63e7","https://git.kernel.org/stable/c/583fdd98d94acba1e7225e5cc29063aef0741030","https://git.kernel.org/stable/c/7a6051d734f1ed0031e2216f9a538621235c11a4","https://git.kernel.org/stable/c/ac79001b8e603226fab17240a79cb9ef679d3cd9","https://git.kernel.org/stable/c/c736ed8541605e3a25075bb1cbf8f38cb3083238","https://git.kernel.org/stable/c/c8af247de385ce49afabc3bf1cf4fd455c94bfe8","https://git.kernel.org/stable/c/d8971f410739a864c537e0ac29344a7b6c450232","https://git.kernel.org/stable/c/f1517721c408631f09d54c743aa70cb07fd3eebd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49921 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sched: Fix use after free in red_enqueue() We can't use "skb" again after passing it to qdisc_enqueue(). This is basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb len before calling child enqueue"). | ["https://git.kernel.org/stable/c/170e5317042c302777ed6d59fdb84af9b0219d4e","https://git.kernel.org/stable/c/52e0429471976785c155bfbf51d80990c6cd46e2","https://git.kernel.org/stable/c/5960b9081baca85cc7dcb14aec1de85999ea9d36","https://git.kernel.org/stable/c/795afe0b9bb6c915f0299a8e309936519be01619","https://git.kernel.org/stable/c/8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9","https://git.kernel.org/stable/c/a238cdcf2bdc72207c74375fc8be13ee549ca9db","https://git.kernel.org/stable/c/e877f8fa49fbccc63cb2df2e9179bddc695b825a","https://git.kernel.org/stable/c/fc4b50adb400ee5ec527a04073174e8e73a139fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21999 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: proc: fix UAF in proc_get_inode() Fix race between rmmod and /proc/XXX's inode instantiation. The bug is that pde->proc_ops don't belong to /proc, it belongs to a module, therefore dereferencing it after /proc entry has been registered is a bug unless use_pde/unuse_pde() pair has been used. use_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops never changes so information necessary for inode instantiation can be saved _before_ proc_register() in PDE itself and used later, avoiding pde->proc_ops->... dereference. rmmod lookup sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove remove_proc_subtree proc_entry_rundown(de); free_module(mod); if (S_ISREG(inode->i_mode)) if (de->proc_ops->proc_read_iter) --> As module is already freed, will trigger UAF BUG: unable to handle page fault for address: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e [adobriyan@gmail.com: don't do 2 atomic ops on the common path] | ["https://git.kernel.org/stable/c/4b0b8445b6fd41e6f62ac90547a0ea9d348de3fa","https://git.kernel.org/stable/c/63b53198aff2e4e6c5866a4ff73c7891f958ffa4","https://git.kernel.org/stable/c/64dc7c68e040251d9ec6e989acb69f8f6ae4a10b","https://git.kernel.org/stable/c/654b33ada4ab5e926cd9c570196fefa7bec7c1df","https://git.kernel.org/stable/c/966f331403dc3ed04ff64eaf3930cf1267965e53","https://git.kernel.org/stable/c/eda279586e571b05dff44d48e05f8977ad05855d","https://git.kernel.org/stable/c/ede3e8ac90ae106f0b29cd759aadebc1568f1308"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22004 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: atm: fix use after free in lec_send() The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free. | ["https://git.kernel.org/stable/c/326223182e4703cde99fdbd36d07d0b3de9980fb","https://git.kernel.org/stable/c/50e288097c2c6e5f374ae079394436fc29d1e88e","https://git.kernel.org/stable/c/51e8be9578a2e74f9983d8fd8de8cafed191f30c","https://git.kernel.org/stable/c/82d9084a97892de1ee4881eb5c17911fcd9be6f6","https://git.kernel.org/stable/c/8cd90c7db08f32829bfa1b5b2b11fbc542afbab7","https://git.kernel.org/stable/c/9566f6ee13b17a15d0a47667ad1b1893c539f730","https://git.kernel.org/stable/c/f3009d0d6ab78053117f8857b921a8237f4d17b3","https://git.kernel.org/stable/c/f3271f7548385e0096739965961c7cbf7e6b4762"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49892 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ftrace: Fix use-after-free for dynamic ftrace_ops KASAN reported a use-after-free with ftrace ops [1]. It was found from vmcore that perf had registered two ops with the same content successively, both dynamic. After unregistering the second ops, a use-after-free occurred. In ftrace_shutdown(), when the second ops is unregistered, the FTRACE_UPDATE_CALLS command is not set because there is another enabled ops with the same content. Also, both ops are dynamic and the ftrace callback function is ftrace_ops_list_func, so the FTRACE_UPDATE_TRACE_FUNC command will not be set. Eventually the value of 'command' will be 0 and ftrace_shutdown() will skip the rcu synchronization. However, ftrace may be activated. When the ops is released, another CPU may be accessing the ops. Add the missing synchronization to fix this problem. [1] BUG: KASAN: use-after-free in __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] BUG: KASAN: use-after-free in ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 Read of size 8 at addr ffff56551965bbc8 by task syz-executor.2/14468 CPU: 1 PID: 14468 Comm: syz-executor.2 Not tainted 5.10.0 #7 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x40c arch/arm64/kernel/stacktrace.c:132 show_stack+0x30/0x40 arch/arm64/kernel/stacktrace.c:196 __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1b4/0x248 lib/dump_stack.c:118 print_address_description.constprop.0+0x28/0x48c mm/kasan/report.c:387 __kasan_report mm/kasan/report.c:547 [inline] kasan_report+0x118/0x210 mm/kasan/report.c:564 check_memory_region_inline mm/kasan/generic.c:187 [inline] __asan_load8+0x98/0xc0 mm/kasan/generic.c:253 __ftrace_ops_list_func kernel/trace/ftrace.c:7020 [inline] ftrace_ops_list_func+0x2b0/0x31c kernel/trace/ftrace.c:7049 ftrace_graph_call+0x0/0x4 __might_sleep+0x8/0x100 include/linux/perf_event.h:1170 __might_fault mm/memory.c:5183 [inline] __might_fault+0x58/0x70 mm/memory.c:5171 do_strncpy_from_user lib/strncpy_from_user.c:41 [inline] strncpy_from_user+0x1f4/0x4b0 lib/strncpy_from_user.c:139 getname_flags+0xb0/0x31c fs/namei.c:149 getname+0x2c/0x40 fs/namei.c:209 [...] Allocated by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track mm/kasan/common.c:56 [inline] __kasan_kmalloc mm/kasan/common.c:479 [inline] __kasan_kmalloc.constprop.0+0x110/0x13c mm/kasan/common.c:449 kasan_kmalloc+0xc/0x14 mm/kasan/common.c:493 kmem_cache_alloc_trace+0x440/0x924 mm/slub.c:2950 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:675 [inline] perf_event_alloc.part.0+0xb4/0x1350 kernel/events/core.c:11230 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 __arm64_sys_perf_event_open+0x6c/0x80 kernel/events/core.c:11723 [...] Freed by task 14445: kasan_save_stack+0x24/0x50 mm/kasan/common.c:48 kasan_set_track+0x24/0x34 mm/kasan/common.c:56 kasan_set_free_info+0x20/0x40 mm/kasan/generic.c:358 __kasan_slab_free.part.0+0x11c/0x1b0 mm/kasan/common.c:437 __kasan_slab_free mm/kasan/common.c:445 [inline] kasan_slab_free+0x2c/0x40 mm/kasan/common.c:446 slab_free_hook mm/slub.c:1569 [inline] slab_free_freelist_hook mm/slub.c:1608 [inline] slab_free mm/slub.c:3179 [inline] kfree+0x12c/0xc10 mm/slub.c:4176 perf_event_alloc.part.0+0xa0c/0x1350 kernel/events/core.c:11434 perf_event_alloc kernel/events/core.c:11733 [inline] __do_sys_perf_event_open kernel/events/core.c:11831 [inline] __se_sys_perf_event_open+0x550/0x15f4 kernel/events/core.c:11723 [...] | ["https://git.kernel.org/stable/c/0e792b89e6800cd9cb4757a76a96f7ef3e8b6294","https://git.kernel.org/stable/c/88561a66777e7a2fe06638c6dcb22a9fae0b6733","https://git.kernel.org/stable/c/cc1b9961a0ceb70f6ca4e2f4b8bb71c87c7a495c","https://git.kernel.org/stable/c/ea5f2fd4640ecbb9df969bf8bb27733ae2183169"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53003 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_info The memory for llcc_driv_data is allocated by the LLCC driver. But when it is passed as the private driver info to the EDAC core, it will get freed during the qcom_edac driver release. So when the qcom_edac driver gets probed again, it will try to use the freed data leading to the use-after-free bug. Hence, do not pass llcc_driv_data as pvt_info but rather reference it using the platform_data pointer in the qcom_edac driver. | ["https://git.kernel.org/stable/c/66e10d5f399629ef7877304d9ba2b35d0474e7eb","https://git.kernel.org/stable/c/6f0351d0c311951b8b3064db91e61841e85b2b96","https://git.kernel.org/stable/c/76d9ebb7f0bc10fbc78b6d576751552edf743968","https://git.kernel.org/stable/c/977c6ba624f24ae20cf0faee871257a39348d4a9","https://git.kernel.org/stable/c/bff5243bd32661cf9ce66f6d9210fc8f89bda145"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21915 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cdx: Fix possible UAF error in driver_override_show() Fixed a possible UAF problem in driver_override_show() in drivers/cdx/cdx.c This function driver_override_show() is part of DEVICE_ATTR_RW, which includes both driver_override_show() and driver_override_store(). These functions can be executed concurrently in sysfs. The driver_override_store() function uses driver_set_override() to update the driver_override value, and driver_set_override() internally locks the device (device_lock(dev)). If driver_override_show() reads cdx_dev->driver_override without locking, it could potentially access a freed pointer if driver_override_store() frees the string concurrently. This could lead to printing a kernel address, which is a security risk since DEVICE_ATTR can be read by all users. Additionally, a similar pattern is used in drivers/amba/bus.c, as well as many other bus drivers, where device_lock() is taken in the show function, and it has been working without issues. This potential bug was detected by our experimental static analysis tool, which analyzes locking APIs and paired functions to identify data races and atomicity violations. | ["https://git.kernel.org/stable/c/0439d541aa8d3444ad41c39e39eb71acb57acde3","https://git.kernel.org/stable/c/8473135f89c0949436a22adb05b8cece2fb3da91","https://git.kernel.org/stable/c/91d44c1afc61a2fec37a9c7a3485368309391e0b","https://git.kernel.org/stable/c/d7b339bbc887bcfc1a5b620bfc70c6fbb8f733bf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21967 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_free_work_struct ->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed. | ["https://git.kernel.org/stable/c/62746ae3f5414244a96293e3b017be637b641280","https://git.kernel.org/stable/c/bb39ed47065455604729404729d9116868638d31","https://git.kernel.org/stable/c/eb51f6f59d19b92f6fe84d3873f958495ab32f0a","https://git.kernel.org/stable/c/fb776765bfc21d5e4ed03bb3d4406c2b86ff1ac3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21969 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd After the hci sync command releases l2cap_conn, the hci receive data work queue references the released l2cap_conn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two. [1] BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837 CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci1 hci_rx_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncated--- | ["https://git.kernel.org/stable/c/7790a79c6fce8d5d552bc64f5c82819f719e4f28","https://git.kernel.org/stable/c/b4f82f9ed43aefa79bec2504ae8c29be0c0f5d1d","https://git.kernel.org/stable/c/c96cce853542b3b13da3738f35ef1be8cfcc9d1d","https://git.kernel.org/stable/c/f8094625a591eeb0b75b1bd9e713fac1d93f5ca9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52603 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: UBSAN: array-index-out-of-bounds in dtSplitRoot Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK> The issue is caused when the value of fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was able to produce value less than -1 which cause the error. This patch simply add the change for the values less than 0. The patch is tested via syzbot. | ["https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16","https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2","https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8","https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af","https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60","https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39","https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f","https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07","https://git.kernel.org/stable/c/27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16","https://git.kernel.org/stable/c/6e2902ecc77e9760a9fc447f56d598383e2372d2","https://git.kernel.org/stable/c/7aa33854477d9c346f5560a1a1fcb3fe7783e2a8","https://git.kernel.org/stable/c/e30b52a2ea3d1e0aaee68096957cf90a2f4ec5af","https://git.kernel.org/stable/c/e4cbc857d75d4e22a1f75446e7480b1f305d8d60","https://git.kernel.org/stable/c/e4ce01c25ccbea02a09a5291c21749b1fc358e39","https://git.kernel.org/stable/c/edff092a59260bf0b0a2eba219cb3da6372c2f9f","https://git.kernel.org/stable/c/fd3486a893778770557649fe28afa5e463d4ed07","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21968 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free on hdcp_work [Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running. [How] Cancel the delayed work when destroying workqueue. (cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128) | ["https://git.kernel.org/stable/c/06acfdef370ae018dad9592369e2d2fd9a40c09e","https://git.kernel.org/stable/c/1397715b011bcdc6ad91b17df7acaee301e89db5","https://git.kernel.org/stable/c/378b361e2e30e9729f9a7676f7926868d14f4326","https://git.kernel.org/stable/c/4964dbc4191ab436877a5e3ecd9c67a4e50b7c36","https://git.kernel.org/stable/c/93d701064e56788663d7c5918fbe5e060d5df587","https://git.kernel.org/stable/c/bac7b8b1a3f1a86eeec85835af106cbdc2b9d9f7","https://git.kernel.org/stable/c/e65e7bea220c3ce8c4c793b4ba35557f4994ab2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21945 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in smb2_lock If smb_lock->zero_len has value, ->llist of smb_lock is not delete and flock is old one. It will cause use-after-free on error handling routine. | ["https://git.kernel.org/stable/c/410ce35a2ed6d0e114132bba29af49b69880c8c7","https://git.kernel.org/stable/c/636e021646cf9b52ddfea7c809b018e91f2188cb","https://git.kernel.org/stable/c/84d2d1641b71dec326e8736a749b7ee76a9599fc","https://git.kernel.org/stable/c/8573571060ca466cbef2c6f03306b2cc7b883506","https://git.kernel.org/stable/c/a0609097fd10d618aed4864038393dd75131289e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4004 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel's netfilter in the way a user triggers the nft_pipapo_remove function with the element, without a NFT_SET_EXT_KEY_END. This issue could allow a local user to crash the system or potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2023:4961","https://access.redhat.com/errata/RHSA-2023:4962","https://access.redhat.com/errata/RHSA-2023:4967","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:5221","https://access.redhat.com/errata/RHSA-2023:5244","https://access.redhat.com/errata/RHSA-2023:5255","https://access.redhat.com/errata/RHSA-2023:5548","https://access.redhat.com/errata/RHSA-2023:5627","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7417","https://access.redhat.com/errata/RHSA-2023:7431","https://access.redhat.com/errata/RHSA-2023:7434","https://access.redhat.com/security/cve/CVE-2023-4004","https://bugzilla.redhat.com/show_bug.cgi?id=2225275","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2023:4961","https://access.redhat.com/errata/RHSA-2023:4962","https://access.redhat.com/errata/RHSA-2023:4967","https://access.redhat.com/errata/RHSA-2023:5069","https://access.redhat.com/errata/RHSA-2023:5091","https://access.redhat.com/errata/RHSA-2023:5093","https://access.redhat.com/errata/RHSA-2023:5221","https://access.redhat.com/errata/RHSA-2023:5244","https://access.redhat.com/errata/RHSA-2023:5255","https://access.redhat.com/errata/RHSA-2023:5548","https://access.redhat.com/errata/RHSA-2023:5627","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7417","https://access.redhat.com/errata/RHSA-2023:7431","https://access.redhat.com/errata/RHSA-2023:7434","https://access.redhat.com/security/cve/CVE-2023-4004","https://bugzilla.redhat.com/show_bug.cgi?id=2225275","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/","https://security.netapp.com/advisory/ntap-20231027-0001/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4139 | High | fixed |
|
An incorrect TLB flush issue was found in the Linux kernel’s GPU i915 kernel driver, potentially leading to random memory corruption or data leaks. This flaw could allow a local user to crash the system or escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2147572","https://security.netapp.com/advisory/ntap-20230309-0004/","https://www.openwall.com/lists/oss-security/2022/11/30/1","https://bugzilla.redhat.com/show_bug.cgi?id=2147572","https://security.netapp.com/advisory/ntap-20230309-0004/","https://www.openwall.com/lists/oss-security/2022/11/30/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49888 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: avoid kprobe recursion The cortex_a76_erratum_1463225_debug_handler() function is called when handling debug exceptions (and synchronous exceptions from BRK instructions), and so is called when a probed function executes. If the compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it can be probed. If cortex_a76_erratum_1463225_debug_handler() is probed, any debug exception or software breakpoint exception will result in recursive exceptions leading to a stack overflow. This can be triggered with the ftrace multiple_probes selftest, and as per the example splat below. This is a regression caused by commit: 6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround") ... which removed the NOKPROBE_SYMBOL() annotation associated with the function. My intent was that cortex_a76_erratum_1463225_debug_handler() would be inlined into its caller, el1_dbg(), which is marked noinstr and cannot be probed. Mark cortex_a76_erratum_1463225_debug_handler() as __always_inline to ensure this. Example splat prior to this patch (with recursive entries elided): | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events | # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable | Insufficient stack space to handle exception! | ESR: 0x0000000096000047 -- DABT (current EL) | FAR: 0xffff800009cefff0 | Task stack: [0xffff800009cf0000..0xffff800009cf4000] | IRQ stack: [0xffff800008000000..0xffff800008004000] | Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0] | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : arm64_enter_el1_dbg+0x4/0x20 | lr : el1_dbg+0x24/0x5c | sp : ffff800009cf0000 | x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068 | x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000 | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 | x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0 | x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4 | x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040 | Kernel panic - not syncing: kernel stack overflow | CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2 | Hardware name: linux,dummy-virt (DT) | Call trace: | dump_backtrace+0xe4/0x104 | show_stack+0x18/0x4c | dump_stack_lvl+0x64/0x7c | dump_stack+0x18/0x38 | panic+0x14c/0x338 | test_taint+0x0/0x2c | panic_bad_stack+0x104/0x118 | handle_bad_stack+0x34/0x48 | __bad_stack+0x78/0x7c | arm64_enter_el1_dbg+0x4/0x20 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 ... | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | cortex_a76_erratum_1463225_debug_handler+0x0/0x34 | el1h_64_sync_handler+0x40/0x98 | el1h_64_sync+0x64/0x68 | do_el0_svc+0x0/0x28 | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x18c/0x190 | Kernel Offset: disabled | CPU features: 0x0080,00005021,19001080 | Memory Limit: none | ---[ end Kernel panic - not syncing: kernel stack overflow ]--- With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined into el1_dbg(), and el1_dbg() cannot be probed: | # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events | sh: write error: No such file or directory | # grep -w cortex_a76_errat ---truncated--- | ["https://git.kernel.org/stable/c/024f4b2e1f874934943eb2d3d288ebc52c79f55c","https://git.kernel.org/stable/c/71d6c33fe223255f4416a01514da2c0bc3e283e7","https://git.kernel.org/stable/c/db66629d43b2d12cb43b004a4ca6be1d03228e97"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52975 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress Bug report and analysis from Ding Hui. During iSCSI session logout, if another task accesses the shost ipaddress attr, we can get a KASAN UAF report like this: [ 276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0 [ 276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088 [ 276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G E 6.1.0-rc8+ #3 [ 276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 276.944470] Call Trace: [ 276.944943] <TASK> [ 276.945397] dump_stack_lvl+0x34/0x48 [ 276.945887] print_address_description.constprop.0+0x86/0x1e7 [ 276.946421] print_report+0x36/0x4f [ 276.947358] kasan_report+0xad/0x130 [ 276.948234] kasan_check_range+0x35/0x1c0 [ 276.948674] _raw_spin_lock_bh+0x78/0xe0 [ 276.949989] iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp] [ 276.951765] show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi] [ 276.952185] dev_attr_show+0x3f/0x80 [ 276.953005] sysfs_kf_seq_show+0x1fb/0x3e0 [ 276.953401] seq_read_iter+0x402/0x1020 [ 276.954260] vfs_read+0x532/0x7b0 [ 276.955113] ksys_read+0xed/0x1c0 [ 276.955952] do_syscall_64+0x38/0x90 [ 276.956347] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.956769] RIP: 0033:0x7f5d3a679222 [ 276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24 [ 276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222 [ 276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003 [ 276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000 [ 276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000 [ 276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58 [ 276.960536] </TASK> [ 276.961357] Allocated by task 2209: [ 276.961756] kasan_save_stack+0x1e/0x40 [ 276.962170] kasan_set_track+0x21/0x30 [ 276.962557] __kasan_kmalloc+0x7e/0x90 [ 276.962923] __kmalloc+0x5b/0x140 [ 276.963308] iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi] [ 276.963712] iscsi_session_setup+0xda/0xba0 [libiscsi] [ 276.964078] iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp] [ 276.964431] iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi] [ 276.964793] iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi] [ 276.965153] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.965546] netlink_unicast+0x4d5/0x7b0 [ 276.965905] netlink_sendmsg+0x78d/0xc30 [ 276.966236] sock_sendmsg+0xe5/0x120 [ 276.966576] ____sys_sendmsg+0x5fe/0x860 [ 276.966923] ___sys_sendmsg+0xe0/0x170 [ 276.967300] __sys_sendmsg+0xc8/0x170 [ 276.967666] do_syscall_64+0x38/0x90 [ 276.968028] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 276.968773] Freed by task 2209: [ 276.969111] kasan_save_stack+0x1e/0x40 [ 276.969449] kasan_set_track+0x21/0x30 [ 276.969789] kasan_save_free_info+0x2a/0x50 [ 276.970146] __kasan_slab_free+0x106/0x190 [ 276.970470] __kmem_cache_free+0x133/0x270 [ 276.970816] device_release+0x98/0x210 [ 276.971145] kobject_cleanup+0x101/0x360 [ 276.971462] iscsi_session_teardown+0x3fb/0x530 [libiscsi] [ 276.971775] iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp] [ 276.972143] iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi] [ 276.972485] iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi] [ 276.972808] netlink_unicast+0x4d5/0x7b0 [ 276.973201] netlink_sendmsg+0x78d/0xc30 [ 276.973544] sock_sendmsg+0xe5/0x120 [ 276.973864] ____sys_sendmsg+0x5fe/0x860 [ 276.974248] ___sys_ ---truncated--- | ["https://git.kernel.org/stable/c/17b738590b97fb3fc287289971d1519ff9b875a1","https://git.kernel.org/stable/c/6f1d64b13097e85abda0f91b5638000afc5f9a06","https://git.kernel.org/stable/c/8859687f5b242c0b057461df0a9ff51d5500783b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50073 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock. | ["https://git.kernel.org/stable/c/0eec592c6a7460ba795d7de29f3dc95cb5422e62","https://git.kernel.org/stable/c/9462f4ca56e7d2430fdb6dcc8498244acbfc4489","https://git.kernel.org/stable/c/bf171b5e86e41de4c1cf32fb7aefa275c3d7de49","https://git.kernel.org/stable/c/c29f192e0d44cc1cbaf698fa1ff198f63556691a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52483 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mctp: perform route lookups under a RCU read-side lock Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net's route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer. Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree. The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates. Based on an analysis from Sili Luo <rootlab@huawei.com>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. | ["https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a","https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4","https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c","https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67","https://git.kernel.org/stable/c/1db0724a01b558feb1ecae551782add1951a114a","https://git.kernel.org/stable/c/2405f64a95a7a094eb24cba9bcfaffd1ea264de4","https://git.kernel.org/stable/c/5093bbfc10ab6636b32728e35813cbd79feb063c","https://git.kernel.org/stable/c/6c52b12159049046483fdb0c411a0a1869c41a67"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4095 | High | fixed |
|
A use-after-free flaw was found in Linux kernel before 5.19.2. This issue occurs in cmd_hdl_filter in drivers/staging/rtl8712/rtl8712_cmd.c, allowing an attacker to launch a local denial of service attack and gain escalation of privileges. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73","https://security.netapp.com/advisory/ntap-20230420-0005/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c53b3dcb9942b8ed7f81ee3921c4085d87070c73","https://security.netapp.com/advisory/ntap-20230420-0005/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52624 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before executing GPINT commands [Why] DMCUB can be in idle when we attempt to interface with the HW through the GPINT mailbox resulting in a system hang. [How] Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep sequence. If the GPINT executes successfully then DMCUB will be put back into sleep after the optional response is returned. It functions similar to the inbox command interface. | ["https://git.kernel.org/stable/c/2ef98c6d753a744e333b7e34b9cf687040fba57d","https://git.kernel.org/stable/c/e5ffd1263dd5b44929c676171802e7b6af483f21","https://git.kernel.org/stable/c/2ef98c6d753a744e333b7e34b9cf687040fba57d","https://git.kernel.org/stable/c/e5ffd1263dd5b44929c676171802e7b6af483f21"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48423 | High | fixed |
|
In the Linux kernel before 6.1.3, fs/ntfs3/record.c does not validate resident attribute names. An out-of-bounds write may occur. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8","https://security.netapp.com/advisory/ntap-20230505-0003/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.3","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=54e45702b648b7c0000e90b3e9b890e367e16ea8","https://security.netapp.com/advisory/ntap-20230505-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22020 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove This fixes the following crash: ================================================================== BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241 CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1 Tainted: [E]=UNSIGNED_MODULE Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024 Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms] Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x27/0x320 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] print_report+0x3e/0x70 kasan_report+0xab/0xe0 ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms] ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms] ? __pfx___schedule+0x10/0x10 ? kick_pool+0x3b/0x270 process_one_work+0x357/0x660 worker_thread+0x390/0x4c0 ? __pfx_worker_thread+0x10/0x10 kthread+0x190/0x1d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 161446: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x1a7/0x470 memstick_alloc_host+0x1f/0xe0 [memstick] rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms] platform_probe+0x60/0xe0 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 bus_probe_device+0xbd/0xd0 device_add+0x4a5/0x760 platform_device_add+0x189/0x370 mfd_add_device+0x587/0x5e0 mfd_add_devices+0xb1/0x130 rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb] usb_probe_interface+0x15c/0x460 call_driver_probe+0x35/0x120 really_probe+0x123/0x410 __driver_probe_device+0xc7/0x1e0 driver_probe_device+0x49/0xf0 __device_attach_driver+0xc6/0x160 bus_for_each_drv+0xe4/0x160 __device_attach+0x13a/0x2b0 rebind_marked_interfaces.isra.0+0xcc/0x110 usb_reset_device+0x352/0x410 usbdev_do_ioctl+0xe5c/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 161506: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x36/0x60 __kasan_slab_free+0x34/0x50 kfree+0x1fd/0x3b0 device_release+0x56/0xf0 kobject_cleanup+0x73/0x1c0 rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms] platform_remove+0x2f/0x50 device_release_driver_internal+0x24b/0x2e0 bus_remove_device+0x124/0x1d0 device_del+0x239/0x530 platform_device_del.part.0+0x19/0xe0 platform_device_unregister+0x1c/0x40 mfd_remove_devices_fn+0x167/0x170 device_for_each_child_reverse+0xc9/0x130 mfd_remove_devices+0x6e/0xa0 rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb] usb_unbind_interface+0xf3/0x3f0 device_release_driver_internal+0x24b/0x2e0 proc_disconnect_claim+0x13d/0x220 usbdev_do_ioctl+0xb5e/0x1860 usbdev_ioctl+0xa/0x20 __x64_sys_ioctl+0xc5/0xf0 do_syscall_64+0x59/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x360 __irq_exit_rcu+0x114/0x130 sysvec_apic_timer_interrupt+0x72/0x90 asm_sysvec_apic_timer_interrupt+0x16/0x20 Second to last potentially related work creation: kasan_save_stack+0x20/0x40 kasan_record_aux_stack+0x85/0x90 insert_work+0x29/0x100 __queue_work+0x34a/0x540 call_timer_fn+0x2a/0x160 expire_timers+0x5f/0x1f0 __run_timer_base.part.0+0x1b6/0x1e0 run_timer_softirq+0x8b/0xe0 handle_softirqs+0xf9/0x ---truncated--- | ["https://git.kernel.org/stable/c/0067cb7d7e7c277e91a0887a3c24e71462379469","https://git.kernel.org/stable/c/31f0eaed6914333f42501fc7e0f6830879f5ef2d","https://git.kernel.org/stable/c/4676741a3464b300b486e70585c3c9b692be1632","https://git.kernel.org/stable/c/52d942a5302eefb3b7a3bfee310a5a33feeedc21","https://git.kernel.org/stable/c/6186fb2cd36317277a8423687982140a7f3f7841","https://git.kernel.org/stable/c/75123adf204f997e11bbddee48408c284f51c050","https://git.kernel.org/stable/c/914c5e5bfceb9878f3056eaf4d1c88f2cbe0a185","https://git.kernel.org/stable/c/9dfaf4d723c62bda8d9d1340e2e78acf0c190439","https://git.kernel.org/stable/c/b094e8e3988e02e8cef7a756c8d2cea9c12509ab"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52935 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/khugepaged: fix ->anon_vma race If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires it to be locked. Page table traversal is allowed under any one of the mmap lock, the anon_vma lock (if the VMA is associated with an anon_vma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retract_page_tables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains). If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them. Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access. Hitting this bug causes a lockdep warning in collapse_and_free_pmd(), in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access. | ["https://git.kernel.org/stable/c/023f47a8250c6bdb4aebe744db4bf7f73414028b","https://git.kernel.org/stable/c/acb08187b5a83cdb9ac4112fae9e18cf983b0128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-5090 | Medium | N/A | A flaw was found in KVM. An improper check in svm_set_x2apic_msr_interception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition. | ["https://access.redhat.com/errata/RHSA-2024:2758","https://access.redhat.com/errata/RHSA-2024:3854","https://access.redhat.com/errata/RHSA-2024:3855","https://access.redhat.com/errata/RHSA-2024:4211","https://access.redhat.com/errata/RHSA-2024:4352","https://access.redhat.com/security/cve/CVE-2023-5090","https://bugzilla.redhat.com/show_bug.cgi?id=2248122","https://access.redhat.com/errata/RHSA-2024:3854","https://access.redhat.com/errata/RHSA-2024:3855","https://access.redhat.com/errata/RHSA-2024:4211","https://access.redhat.com/errata/RHSA-2024:4352","https://access.redhat.com/security/cve/CVE-2023-5090","https://bugzilla.redhat.com/show_bug.cgi?id=2248122"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56747 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb() Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMA memory sb_virt when it fails. Add dma_free_coherent() to free it. This is the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb(). | ["https://git.kernel.org/stable/c/10a6fc486ac40a410f0fb84cc15161238eccd20a","https://git.kernel.org/stable/c/20b775cf274cfbfa3da871a1108877e17b8b19e1","https://git.kernel.org/stable/c/4e48e5b26b3edc0e1dd329201ffc924a7a1f9337","https://git.kernel.org/stable/c/95bbdca4999bc59a72ebab01663d421d6ce5775d","https://git.kernel.org/stable/c/a4d2011cbe039b25024831427b60ab91ee247066","https://git.kernel.org/stable/c/b778b5240485106abf665eb509cc01779ed0cb00","https://git.kernel.org/stable/c/bb8b45883eb072adba297922b67d1467082ac880","https://git.kernel.org/stable/c/cfc76acaf2c4b43d1e140f1e4cbde15adb540bc5","https://git.kernel.org/stable/c/eaf92fad1f21be63427920c12f22227e5f757424"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3303 | Medium | fixed |
|
A race condition flaw was found in the Linux kernel sound subsystem due to improper locking. It could lead to a NULL pointer dereference while handling the SNDCTL_DSP_SYNC ioctl. A privileged local user (root or member of the audio group) could use this flaw to crash the system, resulting in a denial of service condition | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/CAFcO6XN7JDM4xSXGhtusQfS2mSBcx50VJKwQpCq=WeLt57aaZA%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47660 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fsnotify: clear PARENT_WATCHED flags lazily In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users. Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children. When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child. | ["https://git.kernel.org/stable/c/172e422ffea20a89bfdc672741c1aad6fbb5044e","https://git.kernel.org/stable/c/3f3ef1d9f66b93913ce2171120d9226b55acd41d","https://git.kernel.org/stable/c/7ef1d2e240c32b1f337a37232d037b07e3919e1a","https://git.kernel.org/stable/c/d8c42405fc3507cc43ba7e4986a773c3fc633f6e","https://git.kernel.org/stable/c/f9a48bc3dd9099935751458a5bbbea4b7c28abc8","https://git.kernel.org/stable/c/fc1b1e135c3f72382f792e6c319fc088d5523ad5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47668 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: lib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc() If we need to increase the tree depth, allocate a new node, and then race with another thread that increased the tree depth before us, we'll still have a preallocated node that might be used later. If we then use that node for a new non-root node, it'll still have a pointer to the old root instead of being zeroed - fix this by zeroing it in the cmpxchg failure path. | ["https://git.kernel.org/stable/c/0f078f8ca93b28a34e20bd050f12cd4efeee7c0f","https://git.kernel.org/stable/c/0f27f4f445390cb7f73d4209cb2bf32834dc53da","https://git.kernel.org/stable/c/99418ec776a39609f50934720419e0b464ca2283","https://git.kernel.org/stable/c/ad5ee9feebc2eb8cfc76ed74a2d6e55343b0e169","https://git.kernel.org/stable/c/b2f11c6f3e1fc60742673b8675c95b78447f3dae","https://git.kernel.org/stable/c/d942e855324a60107025c116245095632476613e","https://git.kernel.org/stable/c/ebeff038744c498a036e7a92eb8e433ae0a386d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-25012 | Medium | N/A | The Linux kernel through 6.1.9 has a Use-After-Free in bigben_remove in drivers/hid/hid-bigbenff.c via a crafted USB device because the LED controllers remain registered for too long. | ["http://www.openwall.com/lists/oss-security/2023/02/02/1","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://bugzilla.suse.com/show_bug.cgi?id=1207560","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/","https://seclists.org/oss-sec/2023/q1/53","http://www.openwall.com/lists/oss-security/2023/02/02/1","http://www.openwall.com/lists/oss-security/2023/11/05/1","https://bugzilla.suse.com/show_bug.cgi?id=1207560","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d2a2fd844ec7da70d19fabb482304fd1e0595b","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=76ca8da989c7d97a7f76c75d475fe95a584439d7","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9fefb6201c4f8dd9f58c581b2a66e5cde2895ea2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lore.kernel.org/all/20230125-hid-unregister-leds-v1-1-9a5192dcef16%40diag.uniroma1.it/","https://seclists.org/oss-sec/2023/q1/53"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21689 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb() This patch addresses a null-ptr-deref in qt2_process_read_urb() due to an incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; } The condition doesn't account for the valid range of the serial->port buffer, which is from 0 to serial->num_ports - 1. When newport is equal to serial->num_ports, the assignment of "port" in the following code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port]; The fix checks if newport is greater than or equal to serial->num_ports indicating it is out-of-bounds. | ["https://git.kernel.org/stable/c/4b9b41fabcd38990f69ef0cee9c631d954a2b530","https://git.kernel.org/stable/c/575a5adf48b06a2980c9eeffedf699ed5534fade","https://git.kernel.org/stable/c/6068dcff7f19e9fa6fa23ee03453ad6a40fa4efe","https://git.kernel.org/stable/c/6377838560c03b36e1153a42ef727533def9b68f","https://git.kernel.org/stable/c/8542b33622571f54dfc2a267fce378b6e3840b8b","https://git.kernel.org/stable/c/94770cf7c5124f0268d481886829dc2beecc4507","https://git.kernel.org/stable/c/f371471708c7d997f763b0e70565026eb67cc470","https://git.kernel.org/stable/c/fa4c7472469d97c4707698b4c0e098f8cfc2bf22"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21697 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Ensure job pointer is set to NULL after job completion After a job completes, the corresponding pointer in the device must be set to NULL. Failing to do so triggers a warning when unloading the driver, as it appears the job is still active. To prevent this, assign the job pointer to NULL after completing the job, indicating the job has finished. | ["https://git.kernel.org/stable/c/14e0a874488e79086340ba8e2d238cb9596b68a8","https://git.kernel.org/stable/c/1bd6303d08c85072ce40ac01a767ab67195105bd","https://git.kernel.org/stable/c/2a1c88f7ca5c12dff6fa6787492ac910bb9e4407","https://git.kernel.org/stable/c/63195bae1cbf78f1d392b1bc9ae4b03c82d0ebf3","https://git.kernel.org/stable/c/a34050f70e7955a359874dff1a912a748724a140","https://git.kernel.org/stable/c/b22467b1ae104073dcb11aa78562a331cd7fb0e0","https://git.kernel.org/stable/c/e4b5ccd392b92300a2b341705cc4805681094e49"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21699 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gfs2: Truncate address space when flipping GFS2_DIF_JDATA flag Truncate an inode's address space when flipping the GFS2_DIF_JDATA flag: depending on that flag, the pages in the address space will either use buffer heads or iomap_folio_state structs, and we cannot mix the two. | ["https://git.kernel.org/stable/c/2a40a140e11fec699e128170ccaa98b6b82cb503","https://git.kernel.org/stable/c/2b0bd5051ad1c1e9ef4879f18e15a7712c974f3e","https://git.kernel.org/stable/c/4516febe325342555bb09ca5b396fb816d655821","https://git.kernel.org/stable/c/4dd57d1f0e9844311c635a7fb39abce4f2ac5a61","https://git.kernel.org/stable/c/4e3ded34f3f3c9d7ed2aac7be8cf51153646574a","https://git.kernel.org/stable/c/5bb1fd0855bb0abc7d97e44758d6ffed7882d2d0","https://git.kernel.org/stable/c/7c9d9223802fbed4dee1ae301661bf346964c9d2","https://git.kernel.org/stable/c/8c41abc11aa8438c9ed2d973f97e66674c0355df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47631 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: davinci: da850-evm: Avoid NULL pointer dereference With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0 The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall(). Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC. | ["https://git.kernel.org/stable/c/0940795c6834fbe7705acc5c3d4b2f7a5f67527a","https://git.kernel.org/stable/c/0a312ec66a03133d28570f07bc52749ccfef54da","https://git.kernel.org/stable/c/83a1cde5c74bfb44b49cb2a940d044bb2380f4ea","https://git.kernel.org/stable/c/89931d4762572aaee6edbe5673d41f8082de110f","https://git.kernel.org/stable/c/a12b356d45cbb6e8a1b718d1436b3d6239a862f3","https://git.kernel.org/stable/c/c06f476e5b74bcabb8c4a2fba55864a37e62843b","https://git.kernel.org/stable/c/c5628533a3ece64235d04fe11ec44d2be99e423d","https://git.kernel.org/stable/c/c64e2ed5cc376e137e572babfd2edc38b2cfb61b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47638 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubifs: rename_whiteout: Fix double free for whiteout_ui->data 'whiteout_ui->data' will be freed twice if space budget fail for rename whiteout operation as following process: rename_whiteout dev = kmalloc whiteout_ui->data = dev kfree(whiteout_ui->data) // Free first time iput(whiteout) ubifs_free_inode kfree(ui->data) // Double free! KASAN reports: ================================================================== BUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70 Call Trace: kfree+0x117/0x490 ubifs_free_inode+0x4f/0x70 [ubifs] i_callback+0x30/0x60 rcu_do_batch+0x366/0xac0 __do_softirq+0x133/0x57f Allocated by task 1506: kmem_cache_alloc_trace+0x3c2/0x7a0 do_rename+0x9b7/0x1150 [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 Freed by task 1506: kfree+0x117/0x490 do_rename.cold+0x53/0x8a [ubifs] ubifs_rename+0x106/0x1f0 [ubifs] do_syscall_64+0x35/0x80 The buggy address belongs to the object at ffff88810238bed8 which belongs to the cache kmalloc-8 of size 8 ================================================================== Let ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused assignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode() -> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it (because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release', and the nlink of whiteout inode is 0). | ["https://git.kernel.org/stable/c/14276d38c89a170363e90b6ac0a53c3cf61b87fc","https://git.kernel.org/stable/c/2ad07009c459e56ebdcc089d850d664660fdb742","https://git.kernel.org/stable/c/2b3236ecf96db7af5836e1366ce39ace8ce832fa","https://git.kernel.org/stable/c/40a8f0d5e7b3999f096570edab71c345da812e3e","https://git.kernel.org/stable/c/6d7a158a7363c1f6604aa47ae1a280a5c65123dd","https://git.kernel.org/stable/c/8b3c7be16f3f4dfd6e15ac651484e59d3fa36274","https://git.kernel.org/stable/c/a90e2dbe66d2647ff95a0442ad2e86482d977fd8","https://git.kernel.org/stable/c/b9a937f096e608b3368c1abc920d4d640ba2c94f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47651 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: rpmpd: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.". | ["https://git.kernel.org/stable/c/31b5124d742969ea8bf7a1360596f548ca23e770","https://git.kernel.org/stable/c/5a811126d38f9767a20cc271b34db7c8efc5a46c","https://git.kernel.org/stable/c/724376c30af5a57686b223dbcd6188e07d2a1de2","https://git.kernel.org/stable/c/755dbc3d73789ac9f0017c729abf5e4b153bf799","https://git.kernel.org/stable/c/84b89fa877ad576e9ee8130f412cfd592f274508","https://git.kernel.org/stable/c/b5d6eba71997b6d661935d2b15094ac7f9f6132d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49055 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Check for potential null return of kmalloc_array() As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. | ["https://git.kernel.org/stable/c/0a692c625e373fef692ffbc7fc41f8a025f01cb7","https://git.kernel.org/stable/c/1d7a5aae884ca727d41c7ed15d4c82fdb67c040c","https://git.kernel.org/stable/c/32cf90a521dcc0f136db7ee5ba32bfe5f79e460e","https://git.kernel.org/stable/c/40bf32dbfef866c83a3e74800b81d79e52b6d20b","https://git.kernel.org/stable/c/94869bb0de69a812f70231b0eb480bb2f7ae73a6","https://git.kernel.org/stable/c/c7a268b33882d5feaafd29c1734456f41ba41396","https://git.kernel.org/stable/c/ebbb7bb9e80305820dc2328a371c1b35679f2667","https://git.kernel.org/stable/c/f2658d5966bcee8c3eb487875f459756d4f7cdfc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49117 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mips: ralink: fix a refcount leak in ill_acc_of_setup() of_node_put(np) needs to be called when pdev == NULL. | ["https://git.kernel.org/stable/c/060a485df4ec1183d543317511cb4caa43468b5d","https://git.kernel.org/stable/c/142ae7d4f21524acfe073e5a3da5667aa85eb970","https://git.kernel.org/stable/c/4a0a1436053b17e50b7c88858fb0824326641793","https://git.kernel.org/stable/c/5fb47ca3490813d3884d8ad0b2ce511aa3537551","https://git.kernel.org/stable/c/8d7f7ef7980f287ace1c15f2ac03d6754e12f071","https://git.kernel.org/stable/c/c74c755daed551b9aceb8388159180861474bdfe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49137 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. | ["https://git.kernel.org/stable/c/3edd8646cb7c11b57c90e026bda6f21076223f5b","https://git.kernel.org/stable/c/4009f104b02b223d1a11d74b36b1cc083bc37028","https://git.kernel.org/stable/c/72d77ddb2224ebc00648f4f78f8a9a259dccbdf7","https://git.kernel.org/stable/c/927beb05aaa429c883cc0ec6adc48964b187e291","https://git.kernel.org/stable/c/b6d1f7d97c81ebaf2cda9c4c943ee2e484fffdcf","https://git.kernel.org/stable/c/bc2d5c0775c839e2b072884f4ee6a93ba410f107","https://git.kernel.org/stable/c/dfced44f122c500004a48ecc8db516bb6a295a1b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49206 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix memory leak in error flow for subscribe event routine In case the second xa_insert() fails, the obj_event is not released. Fix the error unwind flow to free that memory to avoid a memory leak. | ["https://git.kernel.org/stable/c/0174a89663a5ef83617da15bf24c0af2f62b6c7f","https://git.kernel.org/stable/c/087f9c3f2309ed183f7e4b85ae57121d8663224d","https://git.kernel.org/stable/c/414b4e8738484379f18d6c4e780787c80dbf8a2c","https://git.kernel.org/stable/c/8dd392e352d3269938fea32061a74655a613f929","https://git.kernel.org/stable/c/c98d903ff9e79c210beddea4e6bc15ac38e25aa5","https://git.kernel.org/stable/c/d66498507801fd9a20307a15a0814a0a016c3cde"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49209 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace: <TASK> inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae </TASK> WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30 </TASK> | ["https://git.kernel.org/stable/c/6d03722c34d9603df325f67c6d30dc1b7b3c6067","https://git.kernel.org/stable/c/9c34e38c4a870eb30b13f42f5b44f42e9d19ccb8","https://git.kernel.org/stable/c/bec34a91eba3483e1830c02bdd36f8f968642047","https://git.kernel.org/stable/c/d0b85dfc6f01d26808e2576c6537c131b590e270","https://git.kernel.org/stable/c/de3a8d8fab0710186f7864ec812836d8d70da3c9","https://git.kernel.org/stable/c/f677328f05f52d535cbdc15cb04476db49477eb4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49212 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: atmel: fix refcount issue in atmel_nand_controller_init The reference counting issue happens in several error handling paths on a refcounted object "nc->dmac". In these paths, the function simply returns the error code, forgetting to balance the reference count of "nc->dmac", increased earlier by dma_request_channel(), which may cause refcount leaks. Fix it by decrementing the refcount of specific object in those error paths. | ["https://git.kernel.org/stable/c/0856bf27057561f42b37df111603cf5a0d040294","https://git.kernel.org/stable/c/8baea2b96fa90af8d0f937caf4cf2105ee094d93","https://git.kernel.org/stable/c/9843c9c98f26c6ad843260b19bfdaa2598f2ae1e","https://git.kernel.org/stable/c/9b08d211db4c447eb1a07df65e45e0aa772e0fa6","https://git.kernel.org/stable/c/a3587259ae553e41d1ce8c7435351a5d6b299a11","https://git.kernel.org/stable/c/f1694169f3674cdf7553aed06864254635679878","https://git.kernel.org/stable/c/fe0e2ce5c87e9c0b9485ff566362030aa55972cf","https://git.kernel.org/stable/c/fecbd4a317c95d73c849648c406bcf1b6a0ec1cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49232 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes() In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode() is assigned to mode and is passed to drm_mode_probed_add() directly after that. drm_mode_probed_add() passes &mode->head to list_add_tail(), and there is a dereference of it in list_add_tail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpu_dm_create_common_mode(). Fix this by adding a NULL check of mode. This bug was found by a static analyzer. Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code. | ["https://git.kernel.org/stable/c/19a7eba284790cfbba2945deb2363cf03ce41648","https://git.kernel.org/stable/c/2c729dec8c1e3e2892fde5ce8181553860914e74","https://git.kernel.org/stable/c/57f4ad5e286fe4599c8fc63cf89f85f9eec7f9c9","https://git.kernel.org/stable/c/588a70177df3b1777484267584ef38ab2ca899a2","https://git.kernel.org/stable/c/639b3b9def0a6a3f316a195d705d14113236e89c","https://git.kernel.org/stable/c/bdc7429708a0772d90c208975694f7c2133b1202","https://git.kernel.org/stable/c/f4eaa999fec78dec2a9c2d797438e05cbffb125b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49279 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent integer overflow on 32 bit systems On a 32 bit system, the "len * sizeof(*p)" operation can have an integer overflow. | ["https://git.kernel.org/stable/c/23a9dbbe0faf124fc4c139615633b9d12a3a89ef","https://git.kernel.org/stable/c/303cd6173dce0a28d26526c77814eb90a41bd898","https://git.kernel.org/stable/c/3a2789e8ccb4a3e2a631f6817a2d3bb98b8c4fd8","https://git.kernel.org/stable/c/79b1c54fc6ce09ee0d5fe088bb3de26ae2150e3c","https://git.kernel.org/stable/c/7af164fa2f1abc577d357d22d83a2f3490875d7e","https://git.kernel.org/stable/c/ce1aa09cc14ed625104acc2d487bd92b9a88efe2","https://git.kernel.org/stable/c/e4195d27306ea468a6dc3a27af6f586709951229"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49282 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: quota: fix loop condition at f2fs_quota_sync() cnt should be passed to sb_has_quota_active() instead of type to check active quota properly. Moreover, when the type is -1, the compiler with enough inline knowledge can discard sb_has_quota_active() check altogether, causing a NULL pointer dereference at the following inode_lock(dqopt->files[cnt]): [ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [ 2.796024] Mem abort info: [ 2.796025] ESR = 0x96000005 [ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits [ 2.796029] SET = 0, FnV = 0 [ 2.796031] EA = 0, S1PTW = 0 [ 2.796032] Data abort info: [ 2.796034] ISV = 0, ISS = 0x00000005 [ 2.796035] CM = 0, WnR = 0 [ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000 [ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000 [ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1 [ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT) [ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 2.796065] pc : down_write+0x28/0x70 [ 2.796070] lr : f2fs_quota_sync+0x100/0x294 [ 2.796071] sp : ffffffa3f48ffc30 [ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000 [ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80 [ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001 [ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000 [ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110 [ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038 [ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0 [ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0 [ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000 [ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948 [ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0 [ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a [ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d [ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001 [ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0 [ 2.796098] Call trace: [ 2.796100] down_write+0x28/0x70 [ 2.796102] f2fs_quota_sync+0x100/0x294 [ 2.796104] block_operations+0x120/0x204 [ 2.796106] f2fs_write_checkpoint+0x11c/0x520 [ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34 [ 2.796109] issue_checkpoint_thread+0x6c/0xb8 [ 2.796112] kthread+0x138/0x414 [ 2.796114] ret_from_fork+0x10/0x18 [ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02) [ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]--- [ 2.800116] Kernel panic - not syncing: Fatal exception [ 2.800120] SMP: stopping secondary CPUs | ["https://git.kernel.org/stable/c/680af5b824a52faa819167628665804a14f0e0df","https://git.kernel.org/stable/c/724469814d805820cd37ea789769dba94123ff1a","https://git.kernel.org/stable/c/e58ee6bd939b773675240f5d0f5b88a367c037c4","https://git.kernel.org/stable/c/e9ebf1e8fc50b6a9336f9aea1082d7845e568d0e","https://git.kernel.org/stable/c/f1d5946d47c0827bae39e1537959ce8d6f0224c5","https://git.kernel.org/stable/c/f9156db0987f1b426015d56505e2c58dee70c90d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49301 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in usb_read8() and friends When r8712_usbctrl_vendorreq() returns negative, 'data' in usb_read{8,16,32} will not be initialized. BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:643 [inline] BUG: KMSAN: uninit-value in string+0x4ec/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:643 [inline] string+0x4ec/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 va_format lib/vsprintf.c:1704 [inline] pointer+0x18e6/0x1f70 lib/vsprintf.c:2443 vsnprintf+0x1a9b/0x3650 lib/vsprintf.c:2810 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 dev_vprintk_emit+0x5ef/0x6d0 drivers/base/core.c:4604 dev_printk_emit+0x1dd/0x21f drivers/base/core.c:4615 __dev_printk+0x3be/0x440 drivers/base/core.c:4627 _dev_info+0x1ea/0x22f drivers/base/core.c:4673 r871xu_drv_init+0x1929/0x3070 drivers/staging/rtl8712/usb_intf.c:401 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x6c7/0x1350 drivers/base/dd.c:621 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b91/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5363 [inline] hub_port_connect_change drivers/usb/core/hub.c:5507 [inline] port_event drivers/usb/core/hub.c:5665 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5747 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2289 worker_thread+0x10d0/0x2240 kernel/workqueue.c:2436 kthread+0x3c7/0x500 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 Local variable data created at: usb_read8+0x5d/0x130 drivers/staging/rtl8712/usb_ops.c:33 r8712_read8+0xa5/0xd0 drivers/staging/rtl8712/rtl8712_io.c:29 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 | ["https://git.kernel.org/stable/c/33ef21d55418ab6a62a63fd550b2dbe297433372","https://git.kernel.org/stable/c/58762f1c63c75cbe1dc393eed3c9cf8e38310ca1","https://git.kernel.org/stable/c/95b0f54f8a898072a2810c05fab34d971f23a612","https://git.kernel.org/stable/c/d1b57669732d09da7e13ef86d058dab0cd57f6e0","https://git.kernel.org/stable/c/d7ed3c85da0b230bcdf5329acfe012ed093f3daa","https://git.kernel.org/stable/c/de075af8c404f7d59ed34df230aedd9f645fb846"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49318 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: remove WARN_ON in f2fs_is_valid_blkaddr Syzbot triggers two WARNs in f2fs_is_valid_blkaddr and __is_bitmap_valid. For example, in f2fs_is_valid_blkaddr, if type is DATA_GENERIC_ENHANCE or DATA_GENERIC_ENHANCE_READ, it invokes WARN_ON if blkaddr is not in the right range. The call trace is as follows: f2fs_get_node_info+0x45f/0x1070 read_node_page+0x577/0x1190 __get_node_page.part.0+0x9e/0x10e0 __get_node_page f2fs_get_node_page+0x109/0x180 do_read_inode f2fs_iget+0x2a5/0x58b0 f2fs_fill_super+0x3b39/0x7ca0 Fix these two WARNs by replacing WARN_ON with dump_stack. | ["https://git.kernel.org/stable/c/0a7a1fc7e71eecf2e5053a6c312c9f0dcbb9b8fd","https://git.kernel.org/stable/c/32bea51fe4c6e92c00403739f7547c89219bea88","https://git.kernel.org/stable/c/8c62c5e26345c34d199b4b8c8e69255ba3d0e751","https://git.kernel.org/stable/c/99c09b298e47ebbe345a6da9f268b32a6b0f4582","https://git.kernel.org/stable/c/cd6374af36cc548464d8c47a93fdba7303bb82a4","https://git.kernel.org/stable/c/dc2f78e2d4cc844a1458653d57ce1b54d4a29f21"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49321 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xprtrdma: treat all calls not a bcall when bc_serv is NULL When a rdma server returns a fault format reply, nfs v3 client may treats it as a bcall when bc service is not exist. The debug message at rpcrdma_bc_receive_call are, [56579.837169] RPC: rpcrdma_bc_receive_call: callback XID 00000001, length=20 [56579.837174] RPC: rpcrdma_bc_receive_call: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 After that, rpcrdma_bc_receive_call will meets NULL pointer as, [ 226.057890] BUG: unable to handle kernel NULL pointer dereference at 00000000000000c8 ... [ 226.058704] RIP: 0010:_raw_spin_lock+0xc/0x20 ... [ 226.059732] Call Trace: [ 226.059878] rpcrdma_bc_receive_call+0x138/0x327 [rpcrdma] [ 226.060011] __ib_process_cq+0x89/0x170 [ib_core] [ 226.060092] ib_cq_poll_work+0x26/0x80 [ib_core] [ 226.060257] process_one_work+0x1a7/0x360 [ 226.060367] ? create_worker+0x1a0/0x1a0 [ 226.060440] worker_thread+0x30/0x390 [ 226.060500] ? create_worker+0x1a0/0x1a0 [ 226.060574] kthread+0x116/0x130 [ 226.060661] ? kthread_flush_work_fn+0x10/0x10 [ 226.060724] ret_from_fork+0x35/0x40 ... | ["https://git.kernel.org/stable/c/11270e7ca268e8d61b5d9e5c3a54bd1550642c9c","https://git.kernel.org/stable/c/8dbae5affbdbf524b48000f9d357925bb001e5f4","https://git.kernel.org/stable/c/8e3943c50764dc7c5f25911970c3ff062ec1f18c","https://git.kernel.org/stable/c/90c4f73104016748533a5707ecd15930fbeff402","https://git.kernel.org/stable/c/91784f3d77b73885e1b2e6b59d3cbf0de0a1126a","https://git.kernel.org/stable/c/998d35a2aff4b81a1c784f3aa45cd3afff6814c1","https://git.kernel.org/stable/c/a3fc8051ee061e31db13e2fe011e8e0b71a7f815","https://git.kernel.org/stable/c/da99331fa62131a38a0947a8204c5208de7b0454"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49324 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mips: cpc: Fix refcount leak in mips_cpc_default_phys_base Add the missing of_node_put() to release the refcount incremented by of_find_compatible_node(). | ["https://git.kernel.org/stable/c/1699ec1bfb59304a788901474f6bb003f7831b61","https://git.kernel.org/stable/c/4107fa700f314592850e2c64608f6ede4c077476","https://git.kernel.org/stable/c/8f843cdfc202caaa5d67db3395d893e56362e43a","https://git.kernel.org/stable/c/961ee8a6eeef4632a215d995d837b204f8c7c2d4","https://git.kernel.org/stable/c/aae6b4bb63c694bc91714412718f15468407fe51","https://git.kernel.org/stable/c/bed702566dcdb6ebe300bc0c62bf3600cf4d5874","https://git.kernel.org/stable/c/c667b3872a4c435a3f29d4e15971cd8c378b0043","https://git.kernel.org/stable/c/cc0aed22d33ced9e266c50bdf1cbe668c5acfdf8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49346 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: lantiq_gswip: Fix refcount leak in gswip_gphy_fw_list Every iteration of for_each_available_child_of_node() decrements the reference count of the previous node. when breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the gphy_fw_np. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/0737e018a05e2aa352828c52bdeed3b02cff2930","https://git.kernel.org/stable/c/2e007ac6fa7c9c94ad84da075c5c504afad690a0","https://git.kernel.org/stable/c/32cd78c5610f02a929f63cac985e73692d05f33e","https://git.kernel.org/stable/c/54d6802c4d83fa8de7696cfec06f475d5fd92d27","https://git.kernel.org/stable/c/7c8df6fad43d9d5d77f281f794b2a93cd02fd1a9","https://git.kernel.org/stable/c/c2ae49a113a5344232f1ebb93bcf18bbd11e9c39"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49358 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: memleak flow rule from commit path Abort path release flow rule object, however, commit path does not. Update code to destroy these objects before releasing the transaction. | ["https://git.kernel.org/stable/c/330c0c6cd2150a2d7f47af16aa590078b0d2f736","https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9","https://git.kernel.org/stable/c/80de9ea1f5b808a6601e91111fae601df2b26369","https://git.kernel.org/stable/c/9dd732e0bdf538b1b76dc7c157e2b5e560ff30d3","https://git.kernel.org/stable/c/ab9f34a30c23f656e76f4c5b83125a4e7b53c86e","https://git.kernel.org/stable/c/e33d9bd563e71f6c6528b96008d65524a459c4dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49367 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: mv88e6xxx: Fix refcount leak in mv88e6xxx_mdios_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. mv88e6xxx_mdio_register() pass the device node to of_mdiobus_register(). We don't need the device node after it. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/02ded5a173619b11728b8bf75a3fd995a2c1ff28","https://git.kernel.org/stable/c/42658e47f1abbbe592007d3ba303de466114d0bb","https://git.kernel.org/stable/c/86c3c5f8e4bd1325e24f6fba9017cade29933377","https://git.kernel.org/stable/c/8a1a1255152da4fb934290e7ababc66f24985520","https://git.kernel.org/stable/c/a101793994c0a14c70bb4e44c7fda597eeebba0a","https://git.kernel.org/stable/c/c1df9cb756e5a9ba1841648c44ee5d92306b9c65","https://git.kernel.org/stable/c/dc1cf8c6f9793546696fded437a5b4c84944c48b","https://git.kernel.org/stable/c/e0d763d0c7665c7897e4f5a0847ab0c82543345f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49373 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: watchdog: ts4800_wdt: Fix refcount leak in ts4800_wdt_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() in some error paths. | ["https://git.kernel.org/stable/c/5b110d940417942bc87d9e4bea6d4f24e05ed483","https://git.kernel.org/stable/c/5d24df3d690809952528e7a19a43d84bc5b99d44","https://git.kernel.org/stable/c/7a4afd8a003d6abf1f5d159c2bb67e6b7cbde253","https://git.kernel.org/stable/c/910b1cdf6c50ae8fb222e46657d04fb181577017","https://git.kernel.org/stable/c/91fa5aa53f68b85e779164b3127c7e23cad5c457","https://git.kernel.org/stable/c/f067b5286edfd83d2d3903e8578b561599d62539"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49374 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: check attribute length for bearer name syzbot reported uninit-value: ===================================================== BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] - Do sanity check the attribute length for TIPC_NLA_BEARER_NAME. - Do not use 'illegal name' in printing message. | ["https://git.kernel.org/stable/c/292be63c382ce20673ee61dff1ee9ed4a3dcaae7","https://git.kernel.org/stable/c/3af15272cde28fe5c8489174b8624e232c1775ec","https://git.kernel.org/stable/c/7f36f798f89bf32c0164049cb0e3fd1af613d0bb","https://git.kernel.org/stable/c/8b91d0dfc839e67708c905648cd0e7507a2263e5","https://git.kernel.org/stable/c/92a930fcf4250fe961f6238b99af0bc405799f39","https://git.kernel.org/stable/c/b8fac8e321044a9ac50f7185b4e9d91a7745e4b0","https://git.kernel.org/stable/c/f07670871f4d19e613740eebe210e7e9ea535973"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49382 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: rockchip: Fix refcount leak in rockchip_grf_init of_find_matching_node_and_match returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/042571fe1d171773655ad706715ecc865913d9a4","https://git.kernel.org/stable/c/28133325526b92921f3269fdf97a20d90b92b217","https://git.kernel.org/stable/c/5b3e990f85eb034faa461e691e719e8ce9e2a3c8","https://git.kernel.org/stable/c/69a30b2ed620c2206cbbd1e9c112e4fc584e02bd","https://git.kernel.org/stable/c/8f64e84924604bb969ee1fbc4b8d7d09b9214889","https://git.kernel.org/stable/c/9b59588d8be91c96bfb0371e912ceb4f16315dbf","https://git.kernel.org/stable/c/aab25b669cb9fd3698c2631be4435f4fe92d9e59","https://git.kernel.org/stable/c/d5422f323858cad3ac3581075f9a3a5e0d41c0d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49439 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/fsl_rio: Fix refcount leak in fsl_rio_setup of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/46fd994763cf6884b88a2da712af918f3ed54d7b","https://git.kernel.org/stable/c/51e25fbf20c9152d84a34b7afac15a41fe5c9116","https://git.kernel.org/stable/c/5607a77a365df8c0fd5ff43ac424812b95775527","https://git.kernel.org/stable/c/5b8aa2ba38c010f47c965dd9bb5a8561813ed649","https://git.kernel.org/stable/c/7b668a59ddfb32727e39b06fdf52b28e58c684e0","https://git.kernel.org/stable/c/bcb6c4c5eb4836a21411dfe8247bf9951eb6e7c3","https://git.kernel.org/stable/c/c70dd353d37158e06bf8d450d4b31a7091609924","https://git.kernel.org/stable/c/fcee96924ba1596ca80a6770b2567ca546f9a482"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49451 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix list protocols enumeration in the base protocol While enumerating protocols implemented by the SCMI platform using BASE_DISCOVER_LIST_PROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loop_num_ret' is big enough. Fix the validation avoiding the addition. | ["https://git.kernel.org/stable/c/1052f22e127d0c34c3387bb389424ba1c61491ff","https://git.kernel.org/stable/c/2ccfcd7a09c826516edcfe464b05071961aada3f","https://git.kernel.org/stable/c/444a2d27fe9867d0da4b28fc45b793f32e099ab8","https://git.kernel.org/stable/c/6e7978695f4a6cbd83616b5a702b77fa2087b247","https://git.kernel.org/stable/c/8009120e0354a67068e920eb10dce532391361d0","https://git.kernel.org/stable/c/98342148a8cd242855d7e257f298c966c96dba9f","https://git.kernel.org/stable/c/b0e4bafac8963c2d85ee18d3d01f393735acceec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49459 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/broadcom: Fix potential NULL dereference in sr_thermal_probe platform_get_resource() may return NULL, add proper check to avoid potential NULL dereferencing. | ["https://git.kernel.org/stable/c/61621e042c22b47d1eadee617bdd26835294b425","https://git.kernel.org/stable/c/79098339ac2065f4b4352ef5921628970b6f47e6","https://git.kernel.org/stable/c/b3461ccaa5d2588568d865faee285512ad448049","https://git.kernel.org/stable/c/e20d136ec7d6f309989c447638365840d3424c8e","https://git.kernel.org/stable/c/ee9b6b02e8c140323ed46d6602d805ea735c7719","https://git.kernel.org/stable/c/ef1235c6514a58f274246cf4a2d5f4e40af539ce"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49462 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/a6xx: Fix refcount leak in a6xx_gpu_init of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. a6xx_gmu_init() passes the node to of_find_device_by_node() and of_dma_configure(), of_find_device_by_node() will takes its reference, of_dma_configure() doesn't need the node after usage. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/06907a374f1b74f8f2fb30720dc6df81331e4fb5","https://git.kernel.org/stable/c/48e82ce8cdb19c20a5020fa446b286d6a147450c","https://git.kernel.org/stable/c/65ddbc0d26824e2a5d6154d01d8cf39344900213","https://git.kernel.org/stable/c/6832e36f156ea35a6ed74bca72727806116effdd","https://git.kernel.org/stable/c/c56de483093d7ad0782327f95dda7da97bc4c315","https://git.kernel.org/stable/c/edff4c1af831d0c02e654eed9da7d74174de49d5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49467 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: msm: fix possible memory leak in mdp5_crtc_cursor_set() drm_gem_object_lookup will call drm_gem_object_get inside. So cursor_bo needs to be put when msm_gem_get_and_pin_iova fails. | ["https://git.kernel.org/stable/c/33546183c16c7b9650682dc610bedd732d9c6919","https://git.kernel.org/stable/c/449374565f349d4233beec811d4286fdfe5de44b","https://git.kernel.org/stable/c/656aa3c51fc662064f17179b38ec3ce43af53bca","https://git.kernel.org/stable/c/947a844bb3ebff0f4736d244d792ce129f6700d7","https://git.kernel.org/stable/c/d544880482a5558ec06393b1b3d5dc9275b7a32b","https://git.kernel.org/stable/c/d63ffe3fb3f8327ca21cf91b6a14a2961bc629b4","https://git.kernel.org/stable/c/f8cd192752a1f613b14eee77783c6f0aebb49691"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49472 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: micrel: Allow probing without .driver_data Currently, if the .probe element is present in the phy_driver structure and the .driver_data is not, a NULL pointer dereference happens. Allow passing .probe without .driver_data by inserting NULL checks for priv->type. | ["https://git.kernel.org/stable/c/143878e18001c5a61fcc7ae5c5240323753bb641","https://git.kernel.org/stable/c/1e5fbfc2a6f384e3195446c14bbd3bc298eb88c2","https://git.kernel.org/stable/c/660dfa033ccc9afb032015b6dc76e846bba42cfb","https://git.kernel.org/stable/c/7dcb404662839a4ed1a9703658fee979eb894ca4","https://git.kernel.org/stable/c/91e720b32cba25fa58eaa4c88fe957009cffe9f3","https://git.kernel.org/stable/c/abb5594ae2ba7b82cce85917cc6337ec5d774837","https://git.kernel.org/stable/c/bd219273b4e004a3f853da72e111fc8f81357501","https://git.kernel.org/stable/c/f2ef6f7539c68c6bd6c32323d8845ee102b7c450"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49486 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: fsl: Fix refcount leak in imx_sgtl5000_probe of_find_i2c_device_by_node() takes a reference, In error paths, we should call put_device() to drop the reference to aviod refount leak. | ["https://git.kernel.org/stable/c/41cd312dfe980af869c3503b4d38e62ed20dd3b7","https://git.kernel.org/stable/c/4bfbbfdb3d761323127a67d7d765abe2f77d7b21","https://git.kernel.org/stable/c/7f75e9f629ef54a0845b43889d8ab9dd6e280dd5","https://git.kernel.org/stable/c/922bccdb1796a9e7b989f2bc6d9ada7b499a4329","https://git.kernel.org/stable/c/96fc3da6184af5687e153d420cd7dcdeefdd2f9a","https://git.kernel.org/stable/c/e84aaf23ca82753d765bf84d05295d9d9c5fed29"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49498 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Check for null pointer of pointer substream before dereferencing it Pointer substream is being dereferenced on the assignment of pointer card before substream is being null checked with the macro PCM_RUNTIME_CHECK. Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the the pointer check before card is assigned. | ["https://git.kernel.org/stable/c/011b559be832194f992f73d6c0d5485f5925a10b","https://git.kernel.org/stable/c/1f2e28857be1e5c7db39bbc221332215fc5467e3","https://git.kernel.org/stable/c/7784d22f81a29df2ec57ca90d54f93a35cbcd1a2","https://git.kernel.org/stable/c/b2421a196cb0911ea95aec1050a0b830464c8fa6","https://git.kernel.org/stable/c/b41ef7ad9238c22aa2e142f5ce4ce1a1a0d48123","https://git.kernel.org/stable/c/f2c68c52898f623fe84518da4606538d193b0cca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49517 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. | ["https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102","https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6","https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b","https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912","https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836","https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29","https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39","https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49527 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: venus: hfi: avoid null dereference in deinit If venus_probe fails at pm_runtime_put_sync the error handling first calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets core->ops to NULL, hfi_core_deinit cannot call the core_deinit function anymore. Avoid this null pointer derefence by skipping the call when necessary. | ["https://git.kernel.org/stable/c/0ac84ab50712879eac3c1dd2598440652a85d3d0","https://git.kernel.org/stable/c/0ed5a643b1a4a46b9b7bfba5d468c10cc30e1359","https://git.kernel.org/stable/c/2533acb652359c9e097dfa33587896af782e8a91","https://git.kernel.org/stable/c/27ad46da44177a78a4a0cae6fe03906888c61aa1","https://git.kernel.org/stable/c/86594f6af867b5165d2ba7b5a71fae3a5961e56c","https://git.kernel.org/stable/c/9c385b961d4c378228e80f6abea8509cb67feab6","https://git.kernel.org/stable/c/a21d15dde21d7e8ae047eb8368677407db45d840","https://git.kernel.org/stable/c/b73ed0510bb8d9647cd8e8a4c4c8772bbe545c3a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49608 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ralink: Check for null return of devm_kcalloc Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.". | ["https://git.kernel.org/stable/c/13596e6c9e541e90e5fc2c52b23f08b951370da9","https://git.kernel.org/stable/c/44016a85419ca0d4f1e4d0127b330f8e4e2a57d0","https://git.kernel.org/stable/c/5595d30c4dc27d939635c3188c68203b6ece1711","https://git.kernel.org/stable/c/5694b162f275fb9a9f89422701b2b963be11e496","https://git.kernel.org/stable/c/6194c021496addc11763d1ffa89ce5751889fe3c","https://git.kernel.org/stable/c/c3b821e8e406d5650e587b7ac624ac24e9b780a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49609 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: power/reset: arm-versatile: Fix refcount leak in versatile_reboot_probe of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/493ceca3271316e74639c89ff8ac35883de64256","https://git.kernel.org/stable/c/49fa778ee044b00471dd9ccae5f6a121fffea1ac","https://git.kernel.org/stable/c/6689754b121bd487f99680280102b3a5cd7374af","https://git.kernel.org/stable/c/71ab83ac65e2d671552374123bf920c1d698335a","https://git.kernel.org/stable/c/78bdf732cf5d74d1c6ecda06830a91f80a4aef6f","https://git.kernel.org/stable/c/80192eff64eee9b3bc0594a47381937b94b9d65a","https://git.kernel.org/stable/c/a9ed3ad3a8d1dfbc829d86edb3236873a315db11","https://git.kernel.org/stable/c/b4d224eec96a18fa8959512cd9e5b6a50bd16a41"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49619 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sfp: fix memory leak in sfp_probe() sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). When devm_add_action() fails, sfp is not freed, which leads to a memory leak. We should use devm_add_action_or_reset() instead of devm_add_action(). | ["https://git.kernel.org/stable/c/0a18d802d65cf662644fd1d369c86d84a5630652","https://git.kernel.org/stable/c/1545bc727625ea6e8decd717e5d1e8cc704ccf8f","https://git.kernel.org/stable/c/204543581a2f26bb3b997a304c0bd06926ba7f15","https://git.kernel.org/stable/c/67dc32542a1fb7790d0853cf4a5cf859ac6a2002","https://git.kernel.org/stable/c/9ec5a97f327a89031fce6cfc3e95543c53936638","https://git.kernel.org/stable/c/ede990cfc42775bd0141e21f37ee365dcaeeb50f","https://git.kernel.org/stable/c/f22ddc8a5278d7fb6369a0aeb0d8775a0aefaaee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49620 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: tipc: fix possible refcount leak in tipc_sk_create() Free sk in case tipc_sk_insert() fails. | ["https://git.kernel.org/stable/c/00aff3590fc0a73bddd3b743863c14e76fd35c0c","https://git.kernel.org/stable/c/3b2957fc09fe1ac7f07f40dd50dd5f93e3f3a7a2","https://git.kernel.org/stable/c/4919d82f7041157a421ca9bf39a78551d5ad8a1b","https://git.kernel.org/stable/c/638fa20b618b2bbcf86da71231624cc82121a036","https://git.kernel.org/stable/c/7bc9e7f70bc57d8f02ffea2a42094281effb15ef","https://git.kernel.org/stable/c/833ecd0eae76eadf81d6d747bb5bc992d1151867","https://git.kernel.org/stable/c/ef488669b2652bde5b6ee5a409a5b048a2a50db4","https://git.kernel.org/stable/c/efa78f2ae363428525fb4981bb63c555ee79f3c7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49621 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: pmac32-cpufreq: Fix refcount leak bug In pmac_cpufreq_init_MacRISC3(), we need to add corresponding of_node_put() for the three node pointers whose refcount have been incremented by of_find_node_by_name(). | ["https://git.kernel.org/stable/c/37c16fc2cb13a13f3c0193bfc6f2edef7d7df7d7","https://git.kernel.org/stable/c/3ea9dbf7c2f436952bca331c6f5d72f75aca224e","https://git.kernel.org/stable/c/4513018d0bd739097570d26a7760551cba3deb56","https://git.kernel.org/stable/c/4585890ab2dbf455d80e254d3d859d4c1e357920","https://git.kernel.org/stable/c/4f242486bf46d314b2e3838cc64b56f008a3c4d7","https://git.kernel.org/stable/c/57289b6601fe78c09921599b042a0b430fb420ec","https://git.kernel.org/stable/c/8dda30f81c751b01cd71f2cfaeef26ad4393b1d1","https://git.kernel.org/stable/c/ccd7567d4b6cf187fdfa55f003a9e461ee629e36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49648 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing/histograms: Fix memory leak problem This reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac. As commit 46bbe5c671e0 ("tracing: fix double free") said, the "double free" problem reported by clang static analyzer is: > In parse_var_defs() if there is a problem allocating > var_defs.expr, the earlier var_defs.name is freed. > This free is duplicated by free_var_defs() which frees > the rest of the list. However, if there is a problem allocating N-th var_defs.expr: + in parse_var_defs(), the freed 'earlier var_defs.name' is actually the N-th var_defs.name; + then in free_var_defs(), the names from 0th to (N-1)-th are freed; IF ALLOCATING PROBLEM HAPPENED HERE!!! -+ \ | 0th 1th (N-1)-th N-th V +-------------+-------------+-----+-------------+----------- var_defs: | name | expr | name | expr | ... | name | expr | name | /// +-------------+-------------+-----+-------------+----------- These two frees don't act on same name, so there was no "double free" problem before. Conversely, after that commit, we get a "memory leak" problem because the above "N-th var_defs.name" is not freed. If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th var_defs.expr allocated, then execute on shell like: $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \ /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger Then kmemleak reports: unreferenced object 0xffff8fb100ef3518 (size 8): comm "bash", pid 196, jiffies 4295681690 (age 28.538s) hex dump (first 8 bytes): 76 31 00 00 b1 8f ff ff v1...... backtrace: [<0000000038fe4895>] kstrdup+0x2d/0x60 [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0 [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110 [<0000000066737a4c>] event_trigger_write+0x75/0xd0 [<000000007341e40c>] vfs_write+0xbb/0x2a0 [<0000000087fde4c2>] ksys_write+0x59/0xd0 [<00000000581e9cdf>] do_syscall_64+0x3a/0x80 [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ["https://git.kernel.org/stable/c/22eeff55679d9e7c0f768c79bfbd83e2f8142d89","https://git.kernel.org/stable/c/4d453eb5e1eec89971aa5b3262857ee26cfdffd3","https://git.kernel.org/stable/c/78a1400c42ee11197eb1f0f85ba51df9a4fdfff0","https://git.kernel.org/stable/c/7edc3945bdce9c39198a10d6129377a5c53559c2","https://git.kernel.org/stable/c/eb622d5580b9e2ff694f62da6410618bd73853cb","https://git.kernel.org/stable/c/ecc6dec12c33aa92c086cd702af9f544ddaf3c75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49649 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue xenvif_rx_next_skb() is expecting the rx queue not being empty, but in case the loop in xenvif_rx_action() is doing multiple iterations, the availability of another skb in the rx queue is not being checked. This can lead to crashes: [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.537534] PGD 0 P4D 0 [40072.537644] Oops: 0000 [#1] SMP NOPTI [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 [40072.539211] Call Trace: [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] Fix that by stopping the loop in case the rx queue becomes empty. | ["https://git.kernel.org/stable/c/5a071aefd6414af5a20321ab58a0557b81993687","https://git.kernel.org/stable/c/7425479d20f9e96f7c3ec8e8a93fe0d7478724cb","https://git.kernel.org/stable/c/94e8100678889ab428e68acadf042de723f094b9","https://git.kernel.org/stable/c/b99174ac57fe5d8867448c03b23828e63f24cb1c","https://git.kernel.org/stable/c/b9c32a6886af79d6e0ad87a7b01800ed079cdd02","https://git.kernel.org/stable/c/c0fcceb5f3f1ec197c014fe218c2f28108cacd27","https://git.kernel.org/stable/c/d5320c6a27aa975aff740f9cb481dcbde48f4348","https://git.kernel.org/stable/c/f0b5c819b062df8bf5f2acf4697e3871cb3722da"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49652 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: Fix refcount leak in ti_dra7_xbar_route_allocate of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() in to fix this. | ["https://git.kernel.org/stable/c/37147e22cd8dfc0412495cb361708836157a4486","https://git.kernel.org/stable/c/3bd66010398871807c1cebacee07d60ded1b1402","https://git.kernel.org/stable/c/452b9dfd7aca96befce22634fadb111737f22bbe","https://git.kernel.org/stable/c/61b4ef19c346dc21ab1d4f39f5c412e3037b2bdc","https://git.kernel.org/stable/c/b31ab132561c7f1b6459039152b8d09e44eb3565","https://git.kernel.org/stable/c/b5a817f8d62e9e13280928f3756e54854ae4962e","https://git.kernel.org/stable/c/c132fe78ad7b4ce8b5d49a501a15c29d08eeb23a","https://git.kernel.org/stable/c/cb9813d7eae917acd34436160a278b8b5d48ca53"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49656 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: meson: Fix refcount leak in meson_smp_prepare_cpus of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/2e1bcd33478ef44e63a45457055060b5fe4118ad","https://git.kernel.org/stable/c/34d2cd3fccced12b958b8848e3eff0ee4296764c","https://git.kernel.org/stable/c/3cf8ece9113242c10f83c7675ea4f4f67959ee43","https://git.kernel.org/stable/c/3d90607e7e6afa89768b0aaa915b58bd2b849276","https://git.kernel.org/stable/c/7208101ded1e9dcc52c8f0f8b16474211c871c1a","https://git.kernel.org/stable/c/c5fbf4f74c94fd60d5e9bf9f7f8268c3601562ca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49677 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: cns3xxx: Fix refcount leak in cns3xxx_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/1ba904b6b16e08de5aed7c1349838d9cd0d178c5","https://git.kernel.org/stable/c/45bebbc8cea7d586a6216dc62814bdb380b9b29b","https://git.kernel.org/stable/c/68d4303bf59662b64bd555e2aa0518282d20aa4f","https://git.kernel.org/stable/c/b8b84e01ca94e2e1f5492353e9c24dab520b2e5b","https://git.kernel.org/stable/c/c980392af1473d6d5662f70d8089c8e6d85144a4","https://git.kernel.org/stable/c/d1359e4129ad43e43972a28838b87291c51de23d","https://git.kernel.org/stable/c/da3ee7cd2f15922ad88a7ca6deee2eafdc7cd214","https://git.kernel.org/stable/c/dc5170aae24e04068fd5ea125d06c0ab51f48a27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49678 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. In brcmstb_init_sram, it pass dn to of_address_to_resource(), of_address_to_resource() will call of_find_device_by_node() to take reference, so we should release the reference returned by of_find_matching_node(). | ["https://git.kernel.org/stable/c/10ba9d499a9fd82ed40897e734ba19870a879407","https://git.kernel.org/stable/c/30bbfeb480ae8b5ee43199d72417b232590440c2","https://git.kernel.org/stable/c/37d838de369b07b596c19ff3662bf0293fdb09ee","https://git.kernel.org/stable/c/4f5877bdf7b593e988f1924f4c3df6523f80b39c","https://git.kernel.org/stable/c/734a4d15142bb4c8ecad2d8ec70d7564e78ae34d","https://git.kernel.org/stable/c/dcafd5463d8f20c4f90ddc138a5738adb99f74c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49679 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: Fix refcount leak in axxia_boot_secondary of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/29ca9c4efacccdc15104a8d4bf10b5183fc92840","https://git.kernel.org/stable/c/3c19fe3f04f4f4e7a2b722c2fd3c98356fc1d72b","https://git.kernel.org/stable/c/44a5b3a073e5aaa5720929dba95b2725eb32bb65","https://git.kernel.org/stable/c/4d9c60e868f7cf8e09956e7d5bb44d807d712699","https://git.kernel.org/stable/c/71e12e5b02674459a24f16e965255d63b31fe049","https://git.kernel.org/stable/c/7c7ff68daa93d8c4cdea482da4f2429c0398fcde","https://git.kernel.org/stable/c/a9b76c232a1ce4cbf27862097f7eb634dcc779eb","https://git.kernel.org/stable/c/b385cb59aac8d61c29bc72ebf3d19a536914af96"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49680 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: exynos: Fix refcount leak in exynos_map_pmu of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() checks null pointer. | ["https://git.kernel.org/stable/c/31d09571bb071c20f6bdc0bb7ac1ef8dd2987c04","https://git.kernel.org/stable/c/545ae5cbae839ce39bfe09828e413f1c916082de","https://git.kernel.org/stable/c/68f28d52e6cbab8dcfa249cac4356d1d0573e868","https://git.kernel.org/stable/c/7571bcecf01b69f0d3ec60ca41ce5d4c75411a4a","https://git.kernel.org/stable/c/c4c79525042a4a7df96b73477feaf232fe44ae81","https://git.kernel.org/stable/c/d23f76018e17618559da9eea179d137362023f95","https://git.kernel.org/stable/c/f9b77a52937582a5b99a5a07e4ef1e2f48f87347","https://git.kernel.org/stable/c/fc354856e9fad9cd36e2ad28f9da70716025055a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49681 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xtensa: xtfpga: Fix refcount leak bug in setup In machine_setup(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. | ["https://git.kernel.org/stable/c/0162451723178602c37f0555d235dfa17e486112","https://git.kernel.org/stable/c/0715d0e60052662c3f225342062f174dd721d1c7","https://git.kernel.org/stable/c/173940b3ae40114d4179c251a98ee039dc9cd5b3","https://git.kernel.org/stable/c/35d7e961be68732eb3acaeba81fb81ca16eafd05","https://git.kernel.org/stable/c/6c0839cf1b9e1b3c88da6af76794583cbfae8da3","https://git.kernel.org/stable/c/9b30c5c8884eda3f541229899671cebbad15979b","https://git.kernel.org/stable/c/a52972ee706b438302eb0350e61f378eb191e3d1","https://git.kernel.org/stable/c/b12d5c52f073a0420622aaf2f21b615cce8b36cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49682 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xtensa: Fix refcount leak bug in time.c In calibrate_ccount(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. | ["https://git.kernel.org/stable/c/0dcc1dd8a5dd9240639f1051dfaa2dffc9fbbde5","https://git.kernel.org/stable/c/0e403a383c14b63c86bd9df085b7e573e9caee64","https://git.kernel.org/stable/c/3e5eb904d9ba657308fc75a5de434b0e58dcb8d7","https://git.kernel.org/stable/c/7de4502af68f4f3932f450157f5483eb7b33cb74","https://git.kernel.org/stable/c/a0117dc956429f2ede17b323046e1968d1849150","https://git.kernel.org/stable/c/af0ff2da01521144bc11194f4c26485d7c9cee73","https://git.kernel.org/stable/c/e5234a9d64a976abd134a14710dcd5188158a7c5","https://git.kernel.org/stable/c/f1eaf4ba5372ad111f687a80c67e270708e14c23"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49707 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: add reserved GDT blocks check We capture a NULL pointer issue when resizing a corrupt ext4 image which is freshly clear resize_inode feature (not run e2fsck). It could be simply reproduced by following steps. The problem is because of the resize_inode feature was cleared, and it will convert the filesystem to meta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was not reduced to zero, so could we mistakenly call reserve_backup_gdb() and passing an uninitialized resize_inode to it when adding new group descriptors. mkfs.ext4 /dev/sda 3G tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck mount /dev/sda /mnt resize2fs /dev/sda 8G ======== BUG: kernel NULL pointer dereference, address: 0000000000000028 CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748 ... RIP: 0010:ext4_flex_group_add+0xe08/0x2570 ... Call Trace: <TASK> ext4_resize_fs+0xbec/0x1660 __ext4_ioctl+0x1749/0x24e0 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xa6/0x110 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f2dd739617b ======== The fix is simple, add a check in ext4_resize_begin() to make sure that the es->s_reserved_gdt_blocks is zero when the resize_inode feature is disabled. | ["https://git.kernel.org/stable/c/0dc2fca8e4f9ac4a40e8424a10163369cca0cc06","https://git.kernel.org/stable/c/33b1bba31f4c784d33d2c2517964bdccdc9204cd","https://git.kernel.org/stable/c/7c921328ac760bba780bdace41f4cd045f7f1405","https://git.kernel.org/stable/c/af75c481a2e45e70f62f5942c93695e95bf7bd21","https://git.kernel.org/stable/c/b55c3cd102a6f48b90e61c44f7f3dda8c290c694","https://git.kernel.org/stable/c/b9747263b13e5290ac4d63bec47e38f701303cad","https://git.kernel.org/stable/c/bfd004a1d3a062aac300523d406ac1f3e5f1a82c","https://git.kernel.org/stable/c/fba54289176702a7caac0b64738406775817f451"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49712 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. of_node_put() will check NULL pointer. | ["https://git.kernel.org/stable/c/0ef6917c0524da5b88496b9706628ffef108b9bb","https://git.kernel.org/stable/c/2a598da14856ead80c726b38ba426c68637d9211","https://git.kernel.org/stable/c/46da1e4a8b6329479433b2a4056941dfdd7f3efd","https://git.kernel.org/stable/c/4757c9ade34178b351580133771f510b5ffcf9c8","https://git.kernel.org/stable/c/57901c658f77d9ea2e772f35cb38e47efb54c558","https://git.kernel.org/stable/c/727c82d003e0ec64411fd1257a9a57de4ad7a99a","https://git.kernel.org/stable/c/b75bddfcc18170ce8e3fb695a76ec2dec4ce0ea5","https://git.kernel.org/stable/c/d85e4e6284a91aa2d1ab004e9d84b9c09b4aa203"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49713 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: Fix memory leak in dwc2_hcd_init usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when platform_get_resource() fails to prevent memory leak. goto error2 label instead error1 to fix this. | ["https://git.kernel.org/stable/c/3755278f078460b021cd0384562977bf2039a57a","https://git.kernel.org/stable/c/52bfcedbfd5bf962dbdcb6e761f4d0dd3ba26dfd","https://git.kernel.org/stable/c/6506aff2dc2f7059aa3d45ee2e8639b25e87090f","https://git.kernel.org/stable/c/701d8ec01e0f229d4db6f43d3d64ee479120cbeb","https://git.kernel.org/stable/c/84e6d0af87e27bbc0db94f2e7323b34abe17b6e5","https://git.kernel.org/stable/c/981ee40649e5fd9550f82db1fbb3bfab037da346","https://git.kernel.org/stable/c/a44a8a762f7fe9ad3c065813d058e835a6180cb2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49715 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix refcount leak in gic_populate_ppi_partitions of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/506a88a5bf261d76a5214c0338a320f2214c67ac","https://git.kernel.org/stable/c/8d884c08eeb83142a7173cb46bcff0434ec42cf1","https://git.kernel.org/stable/c/c136c2924a59a399aa789858cfb320d481964fb7","https://git.kernel.org/stable/c/cc5984cf270b69d03f9f4b27063e535036c659e9","https://git.kernel.org/stable/c/e824482e2c5edacc961b7dd30a92fd47606c3036","https://git.kernel.org/stable/c/fa1ad9d4cc47ca2470cd904ad4519f05d7e43a2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49719 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic/realview: Fix refcount leak in realview_gic_of_init of_find_matching_node_and_match() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/16b603cb8d34c2d917983918db1f88c8b831baaa","https://git.kernel.org/stable/c/486f68f85085d9b16ae097679b1486dcb1b6eb69","https://git.kernel.org/stable/c/56526c3883fc7a1f5898b1d40a02c8b8685a5d92","https://git.kernel.org/stable/c/5d38720661a4b9c87705c206a6081177ffb8ec1d","https://git.kernel.org/stable/c/87da903ce632d5689bef66d56ee5dae700d82104","https://git.kernel.org/stable/c/b634af84bc1edece4e63317b0ad95618dd3a8693","https://git.kernel.org/stable/c/e52a58b79f11755ea7e877015c4a1704303fa55f","https://git.kernel.org/stable/c/f4b98e314888cc51486421bcf6d52852452ea48b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49729 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix memory leak in nfcmrvl_play_deferred Similar to the handling of play_deferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"), we thought a patch might be needed here as well. Currently usb_submit_urb is called directly to submit deferred tx urbs after unanchor them. So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb and cause memory leak. Put those urbs in tx_anchor to avoid the leak, and also fix the error handling. | ["https://git.kernel.org/stable/c/0eeec1a8b0cd38c47edeb042980a6aeacecf35ed","https://git.kernel.org/stable/c/1eb0afecfb9cd0f38424b82bd9aaa542310934ee","https://git.kernel.org/stable/c/3e7c7df6991ac349f2fa8540047757df666e610f","https://git.kernel.org/stable/c/3eadc560c1919b8193d17334145dad9a917960e4","https://git.kernel.org/stable/c/6616872cfe7f0474a22dd1f12699f95bcf81a54d","https://git.kernel.org/stable/c/6b4d8b44e7163a77fe942f5b80e1651c1b78c537","https://git.kernel.org/stable/c/8a4d480702b71184fabcf379b80bf7539716752e","https://git.kernel.org/stable/c/f21f908347712b8288ffe83b531b5e977042b29c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21814 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ptp: Ensure info->enable callback is always set The ioctl and sysfs handlers unconditionally call the ->enable callback. Not all drivers implement that callback, leading to NULL dereferences. Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c. Instead use a dummy callback if no better was specified by the driver. | ["https://git.kernel.org/stable/c/1334c64a5d1de6666e0c9f984db6745083df1eb4","https://git.kernel.org/stable/c/5d1041c76de656f9f8d5a192218039a9acf9bd00","https://git.kernel.org/stable/c/755caf4ee1c615ee5717862e427124370f46b1f3","https://git.kernel.org/stable/c/81846070cba17125a866e8023c01d3465b153339","https://git.kernel.org/stable/c/8441aea46445252df5d2eed6deb6d5246fc24002","https://git.kernel.org/stable/c/9df3a9284f39bfd51a9f72a6a165c79e2aa5066b","https://git.kernel.org/stable/c/fd53aa40e65f518453115b6f56183b0c201db26b","https://git.kernel.org/stable/c/fdc1e72487781dd7705bcbe30878bee7d5d1f3e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47644 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: move videodev alloc Move some code out of zr36057_init() and create new functions for handling zr->video_dev. This permit to ease code reading and fix a zr->video_dev memory leak. | ["https://git.kernel.org/stable/c/1e501ec38796f43e995731d1bcd4173cb1ccfce0","https://git.kernel.org/stable/c/82e3a496eb56da0b9f29fdc5b63cedb3289e91de","https://git.kernel.org/stable/c/bd01629315ffd5b63da91d0bd529a77d30e55028","https://git.kernel.org/stable/c/c1ba65100a359fe28cfe37e09e10c99f247cbf1e","https://git.kernel.org/stable/c/ff3357bffd9fb78f59762d8955afc7382a279079"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47645 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com On the case tmp_dcim=1, the index of buffer is miscalculated. This generate a NULL pointer dereference later. So let's fix the calcul and add a check to prevent this to reappear. | ["https://git.kernel.org/stable/c/20811bbe685ca3eddd34b0c750860427d7030910","https://git.kernel.org/stable/c/20db2ed1e2f9fcd417fa67853e5154f0c2537d6c","https://git.kernel.org/stable/c/7e76f3ed7ab2ae026c6ef9cc23096a7554af8c52","https://git.kernel.org/stable/c/bafec1a6ba4b187a7fcdcfce0faebdc623d4ef8e","https://git.kernel.org/stable/c/e3b86f4e558cea9eed71d894df2f19b10d60a207"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47648 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpu: host1x: Fix a memory leak in 'host1x_remove()' Add a missing 'host1x_channel_list_free()' call in the remove function, as already done in the error handling path of the probe function. | ["https://git.kernel.org/stable/c/025c6643a81564f066d8381b9e2f4603e0f8438f","https://git.kernel.org/stable/c/5124a344983e1b9670dae7add0e4d00d589aabcd","https://git.kernel.org/stable/c/6bb107332db28a0e9256c2d36a0902b85307612c","https://git.kernel.org/stable/c/c06577a80485511b894cb688e881ef0bc2d1d296","https://git.kernel.org/stable/c/fe1ce680560d4f0049ffa0c687de17567421c1ec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49060 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name(). | ["https://git.kernel.org/stable/c/22025513ced3d599ee8b24169141c95cf2467a4a","https://git.kernel.org/stable/c/35b91e49bc80ca944a8679c3b139ddaf2f8eea0f","https://git.kernel.org/stable/c/3a523807f01455fe9a0c1a433f27cd4411ee400f","https://git.kernel.org/stable/c/a05f5e26cb8bb4d07e0595545fcad1bb406f0085","https://git.kernel.org/stable/c/d22f4f977236f97e01255a80bca2ea93a8094fc8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49061 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link When using a fixed-link, the altr_tse_pcs driver crashes due to null-pointer dereference as no phy_device is provided to tse_pcs_fix_mac_speed function. Fix this by adding a check for phy_dev before calling the tse_pcs_fix_mac_speed() function. Also clean up the tse_pcs_fix_mac_speed function a bit. There is no need to check for splitter_base and sgmii_adapter_base because the driver will fail if these 2 variables are not derived from the device tree. | ["https://git.kernel.org/stable/c/08d5e3e954537931c8da7428034808d202e98299","https://git.kernel.org/stable/c/62a48383ebe2e159fd68425dd3e16d4c6bd6599a","https://git.kernel.org/stable/c/6c020f05253df04c3480b586fe188a3582740049","https://git.kernel.org/stable/c/7e59fdf9547c4f948d1d917ec7ffa5fb5ac53bdb","https://git.kernel.org/stable/c/a6aaa00324240967272b451bfa772547bd576ee6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49103 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix reference count leaks in _nfs42_proc_copy_notify() [You don't often get email from xiongx18@fudan.edu.cn. Learn why this is important at http://aka.ms/LearnAboutSenderIdentification.] The reference counting issue happens in two error paths in the function _nfs42_proc_copy_notify(). In both error paths, the function simply returns the error code and forgets to balance the refcount of object `ctx`, bumped by get_nfs_open_context() earlier, which may cause refcount leaks. Fix it by balancing refcount of the `ctx` object before the function returns in both error paths. | ["https://git.kernel.org/stable/c/9b9feec97c1fc7dd9bb69f62c4905cddf1801599","https://git.kernel.org/stable/c/b37f482ba9f0e6382c188e3fccf6c4b2fdc938eb","https://git.kernel.org/stable/c/b7f114edd54326f730a754547e7cfb197b5bc132","https://git.kernel.org/stable/c/f46f632f9cfae4b2e3635fa58840a8ec584c42e3","https://git.kernel.org/stable/c/fb73bf6305f4eb8f0cf9a61ee874d55f019d6dc4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49104 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_core: handle NULL result of find_service_by_handle In case of an invalid handle the function find_servive_by_handle returns NULL. So take care of this and avoid a NULL pointer dereference. | ["https://git.kernel.org/stable/c/04202f54dd8899e10f56a89c4c1ede0043fa22af","https://git.kernel.org/stable/c/3b424f6586a870b8d657c5e5419465bbe0e7b61f","https://git.kernel.org/stable/c/42f2142a337ee372455574809fc924580a7e51b2","https://git.kernel.org/stable/c/aa0b7296785312a4bfa8fac0ba8ad78698fd9fcf","https://git.kernel.org/stable/c/ca225857faf237234d2fffe5d1919467dfadd822"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49105 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: wfx: fix an error handling in wfx_init_common() One error handler of wfx_init_common() return without calling ieee80211_free_hw(hw), which may result in memory leak. And I add one err label to unify the error handler, which is useful for the subsequent changes. | ["https://git.kernel.org/stable/c/60f1d3c92dc1ef1026e5b917a329a7fa947da036","https://git.kernel.org/stable/c/86efcb524ae1889ae73f2a2f0bb7fff2ec757ab0","https://git.kernel.org/stable/c/93498c6e775ae91732a8109dba1bdcd324908f84","https://git.kernel.org/stable/c/9727912e906762a63c1a667c84731d3427653f88","https://git.kernel.org/stable/c/ab0fed1fa744173433cfd1dbaf9239f200ded650"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49107 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: fix memory leak in ceph_readdir when note_last_dentry returns error Reset the last_readdir at the same time, and add a comment explaining why we don't free last_readdir when dir_emit returns false. | ["https://git.kernel.org/stable/c/2fe82d3254029ef9ec4e7be890125d5ef4f537de","https://git.kernel.org/stable/c/7f740ede35132d3d5d19747cad56a511d21bb156","https://git.kernel.org/stable/c/e792575b902a3939ca482491ee9fb3a236f99640","https://git.kernel.org/stable/c/f4429786129648a8f4bb1e5faa143c4478cc5c4a","https://git.kernel.org/stable/c/f639d9867eea647005dc824e0e24f39ffc50d4e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49113 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/secvar: fix refcount leak in format_show() Refcount leak will happen when format_show returns failure in multiple cases. Unified management of of_node_put can fix this problem. | ["https://git.kernel.org/stable/c/02222bf4f0a27f6eba66d1f597cdb5daadd51829","https://git.kernel.org/stable/c/2a71e3ecd829a82013cf095c55068c61d991e885","https://git.kernel.org/stable/c/c105ffb6b9744158e37e9f81f0f38861951d1c1f","https://git.kernel.org/stable/c/d05e4265d33af60b39606c20c731e3e719bfe3d6","https://git.kernel.org/stable/c/d601fd24e6964967f115f036a840f4f28488f63f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49115 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix misused goto label Fix a misused goto label jump since that can result in a memory leak. | ["https://git.kernel.org/stable/c/70236a0d2d62b081d52076de22d8d017d6cbe99f","https://git.kernel.org/stable/c/7c657c0694ff690e361a13ce41c36b9dfb433ec8","https://git.kernel.org/stable/c/bf8d87c076f55b8b4dfdb6bc6c6b6dc0c2ccb487","https://git.kernel.org/stable/c/d3642fc64276b06446290f82fd45630aeaa4b007","https://git.kernel.org/stable/c/dc9d33b2d8d09e6478e8ef817a81cf26930acc3e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49116 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: use memset avoid memory leaks Use memset to initialize structs to prevent memory leaks in l2cap_ecred_connect | ["https://git.kernel.org/stable/c/42b6a39f439b6f37cc2024d91ce547d83290ff78","https://git.kernel.org/stable/c/9567d54e70ff58c2695c2cc2e53c86c67551d3e6","https://git.kernel.org/stable/c/d3715b2333e9a21692ba16ef8645eda584a9515d","https://git.kernel.org/stable/c/d588c183a971b85c775ad66da563ee6e8bc8158f","https://git.kernel.org/stable/c/e9e55acee9b7a737ec7f5161b94a78932a5514c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49119 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix memory leak in pm8001_chip_fw_flash_update_req() In pm8001_chip_fw_flash_update_build(), if pm8001_chip_fw_flash_update_build() fails, the struct fw_control_ex allocated must be freed. | ["https://git.kernel.org/stable/c/a25ed5f21f94f9ae4bcc8dd747e978668890c921","https://git.kernel.org/stable/c/d83574666bac4b1462e90df393fbed6c5f57d1a3","https://git.kernel.org/stable/c/e5ecdb01952f230921aa8163d8d7f4c97c925ed8","https://git.kernel.org/stable/c/f792a3629f4c4aa4c3703d66b43ce1edcc3ec09a","https://git.kernel.org/stable/c/fe5b8ea5583b5c3f6f68e06acba50387edf3b5d5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49130 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath11k: mhi: use mhi_sync_power_up() If amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The reason for that was that we were using mhi_async_power_up() which does not check any errors. But mhi_sync_power_up() on the other hand does check for errors so let's use that to fix the crash. I was not able to find a reason why an async version was used. ath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from ath11k_hif_power_up(), which can sleep. So sync version should be safe to use here. [ 145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI [ 145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G W 5.16.0-wt-ath+ #567 [ 145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 [ 145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k] [ 145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08 [ 145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246 [ 145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455 [ 145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80 [ 145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497 [ 145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000 [ 145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8 [ 145.570465] FS: 00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000 [ 145.570519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0 [ 145.570623] Call Trace: [ 145.570675] <TASK> [ 145.570727] ? ath11k_ce_tx_process_cb+0x34b/0x860 [ath11k] [ 145.570797] ath11k_ce_tx_process_cb+0x356/0x860 [ath11k] [ 145.570864] ? tasklet_init+0x150/0x150 [ 145.570919] ? ath11k_ce_alloc_pipes+0x280/0x280 [ath11k] [ 145.570986] ? tasklet_clear_sched+0x42/0xe0 [ 145.571042] ? tasklet_kill+0xe9/0x1b0 [ 145.571095] ? tasklet_clear_sched+0xe0/0xe0 [ 145.571148] ? irq_has_action+0x120/0x120 [ 145.571202] ath11k_ce_cleanup_pipes+0x45a/0x580 [ath11k] [ 145.571270] ? ath11k_pci_stop+0x10e/0x170 [ath11k_pci] [ 145.571345] ath11k_core_stop+0x8a/0xc0 [ath11k] [ 145.571434] ath11k_core_deinit+0x9e/0x150 [ath11k] [ 145.571499] ath11k_pci_remove+0xd2/0x260 [ath11k_pci] [ 145.571553] pci_device_remove+0x9a/0x1c0 [ 145.571605] __device_release_driver+0x332/0x660 [ 145.571659] driver_detach+0x1e7/0x2c0 [ 145.571712] bus_remove_driver+0xe2/0x2d0 [ 145.571772] pci_unregister_driver+0x21/0x250 [ 145.571826] __do_sys_delete_module+0x30a/0x4b0 [ 145.571879] ? free_module+0xac0/0xac0 [ 145.571933] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370 [ 145.571986] ? syscall_enter_from_user_mode+0x1d/0x50 [ 145.572039] ? lockdep_hardirqs_on+0x79/0x100 [ 145.572097] do_syscall_64+0x3b/0x90 [ 145.572153] entry_SYSCALL_64_after_hwframe+0x44/0xae Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2 | ["https://git.kernel.org/stable/c/20d01a11efde2e05e47d5c66101f5c26eaca68e2","https://git.kernel.org/stable/c/339bd0b55ecdd0f7f341e9357c4cfde799de9418","https://git.kernel.org/stable/c/3df6d74aedfdca919cca475d15dfdbc8b05c9e5d","https://git.kernel.org/stable/c/3fd7d50384c3808b7f7fa135aa9bb5feb1cb9849","https://git.kernel.org/stable/c/646d533af2911be1184eaee8c900b7eb8ecc4396"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49131 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath11k: fix kernel panic during unload/load ath11k modules Call netif_napi_del() from ath11k_ahb_free_ext_irq() to fix the following kernel panic when unload/load ath11k modules for few iterations. [ 971.201365] Unable to handle kernel paging request at virtual address 6d97a208 [ 971.204227] pgd = 594c2919 [ 971.211478] [6d97a208] *pgd=00000000 [ 971.214120] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 971.412024] CPU: 2 PID: 4435 Comm: insmod Not tainted 5.4.89 #0 [ 971.434256] Hardware name: Generic DT based system [ 971.440165] PC is at napi_by_id+0x10/0x40 [ 971.445019] LR is at netif_napi_add+0x160/0x1dc [ 971.743127] (napi_by_id) from [<807d89a0>] (netif_napi_add+0x160/0x1dc) [ 971.751295] (netif_napi_add) from [<7f1209ac>] (ath11k_ahb_config_irq+0xf8/0x414 [ath11k_ahb]) [ 971.759164] (ath11k_ahb_config_irq [ath11k_ahb]) from [<7f12135c>] (ath11k_ahb_probe+0x40c/0x51c [ath11k_ahb]) [ 971.768567] (ath11k_ahb_probe [ath11k_ahb]) from [<80666864>] (platform_drv_probe+0x48/0x94) [ 971.779670] (platform_drv_probe) from [<80664718>] (really_probe+0x1c8/0x450) [ 971.789389] (really_probe) from [<80664cc4>] (driver_probe_device+0x15c/0x1b8) [ 971.797547] (driver_probe_device) from [<80664f60>] (device_driver_attach+0x44/0x60) [ 971.805795] (device_driver_attach) from [<806650a0>] (__driver_attach+0x124/0x140) [ 971.814822] (__driver_attach) from [<80662adc>] (bus_for_each_dev+0x58/0xa4) [ 971.823328] (bus_for_each_dev) from [<80663a2c>] (bus_add_driver+0xf0/0x1e8) [ 971.831662] (bus_add_driver) from [<806658a4>] (driver_register+0xa8/0xf0) [ 971.839822] (driver_register) from [<8030269c>] (do_one_initcall+0x78/0x1ac) [ 971.847638] (do_one_initcall) from [<80392524>] (do_init_module+0x54/0x200) [ 971.855968] (do_init_module) from [<803945b0>] (load_module+0x1e30/0x1ffc) [ 971.864126] (load_module) from [<803948b0>] (sys_init_module+0x134/0x17c) [ 971.871852] (sys_init_module) from [<80301000>] (ret_fast_syscall+0x0/0x50) Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.6.0.1-00760-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/22b59cb965f79ee1accf83172441c9ca0ecb632a","https://git.kernel.org/stable/c/38e488db194dc16d2eb23c77c6a8c04ff583c40d","https://git.kernel.org/stable/c/699e8c87e5c406af0f0606f40eeebd248c51b702","https://git.kernel.org/stable/c/c4b7653af62a9a5efe2856183d1f987c5429758b","https://git.kernel.org/stable/c/c6a815f5abdf324108799829dd19ea62fef4bf95"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49139 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix null ptr deref on hci_sync_conn_complete_evt This event is just specified for SCO and eSCO link types. On the reception of a HCI_Synchronous_Connection_Complete for a BDADDR of an existing LE connection, LE link type and a status that triggers the second case of the packet processing a NULL pointer dereference happens, as conn->link is NULL. | ["https://git.kernel.org/stable/c/0f9db1209f59844839175b5b907d3778cafde93d","https://git.kernel.org/stable/c/1c1291a84e94f6501644634c97544bb8291e9a1a","https://git.kernel.org/stable/c/3afee2118132e93e5f6fa636dfde86201a860ab3","https://git.kernel.org/stable/c/c1aa0dd52db4ce888be0bd820c3fa918d350ca0b","https://git.kernel.org/stable/c/f61c23e73dc653b957781066abfa8105c3fa3f5b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49144 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: fix memory leak of uid in files registration When there are no files for __io_sqe_files_scm() to process in the range, it'll free everything and return. However, it forgets to put uid. | ["https://git.kernel.org/stable/c/0853bd6885c2f293d88aaa7f7f1702c959b31680","https://git.kernel.org/stable/c/7fa8b228c3f30060b9f4b24bb9aaaf41b0ae83fe","https://git.kernel.org/stable/c/b27de7011cb3ba14b047be2cee0ed8278368665b","https://git.kernel.org/stable/c/c86d18f4aa93e0e66cda0e55827cd03eea6bc5f8","https://git.kernel.org/stable/c/d6d7a517e81accf6ed22d55684baea763d2dbe43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49148 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: watch_queue: Free the page array when watch_queue is dismantled Commit 7ea1a0124b6d ("watch_queue: Free the alloc bitmap when the watch_queue is torn down") took care of the bitmap, but not the page array. BUG: memory leak unreferenced object 0xffff88810d9bc140 (size 32): comm "syz-executor335", pid 3603, jiffies 4294946994 (age 12.840s) hex dump (first 32 bytes): 40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00 @.@............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: kmalloc_array include/linux/slab.h:621 [inline] kcalloc include/linux/slab.h:652 [inline] watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251 pipe_ioctl+0x82/0x140 fs/pipe.c:632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] | ["https://git.kernel.org/stable/c/375cd2536494cfbcdda84ae8b3e35bf19d0250b9","https://git.kernel.org/stable/c/3963a5d1ff75585bddf0c3a918566a6be09d7520","https://git.kernel.org/stable/c/4913daecd04addb41bc96a9175a885e1c19862a8","https://git.kernel.org/stable/c/7169f60110915c8b53bffd43741fa020a75eb87a","https://git.kernel.org/stable/c/b490207017ba237d97b735b2aa66dc241ccd18f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49153 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wireguard: socket: free skb in send6 when ipv6 is disabled I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. | ["https://git.kernel.org/stable/c/096f9d35cac0a0c95ffafc00db84786b665a4837","https://git.kernel.org/stable/c/0b19bcb753dbfb74710d12bb2761ec5ed706c726","https://git.kernel.org/stable/c/402991a9771587acc2947cf6c4d689c5397f2258","https://git.kernel.org/stable/c/bbbf962d9460194993ee1943a793a0a0af4a7fbf","https://git.kernel.org/stable/c/ebcc492f4ba14bae54b898f1016a37b4282558d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49190 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kernel/resource: fix kfree() of bootmem memory again Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case. | ["https://git.kernel.org/stable/c/0cbcc92917c5de80f15c24d033566539ad696892","https://git.kernel.org/stable/c/3379a60f6bb4afcd9c456e340ac525ae649d3ce7","https://git.kernel.org/stable/c/a9e88c2618d228d7a4e7e515cf30dc0d0d813f27","https://git.kernel.org/stable/c/ab86020070999e758ce2e60c4348f20bf7ddba56","https://git.kernel.org/stable/c/d7faa04a44a0c37ac3d222fa8e0bdcbfcee9c0c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49210 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: MIPS: pgalloc: fix memory leak caused by pgd_free() pgd page is freed by generic implementation pgd_free() since commit f9cb654cb550 ("asm-generic: pgalloc: provide generic pgd_free()"), however, there are scenarios that the system uses more than one page as the pgd table, in such cases the generic implementation pgd_free() won't be applicable anymore. For example, when PAGE_SIZE_4KB is enabled and MIPS_VA_BITS_48 is not enabled in a 64bit system, the macro "PGD_ORDER" will be set as "1", which will cause allocating two pages as the pgd table. Well, at the same time, the generic implementation pgd_free() just free one pgd page, which will result in the memory leak. The memory leak can be easily detected by executing shell command: "while true; do ls > /dev/null; grep MemFree /proc/meminfo; done" | ["https://git.kernel.org/stable/c/1bf0d78c8cc3cf615a6e7bf33ada70b73592f0a1","https://git.kernel.org/stable/c/2bc5bab9a763d520937e4f3fe8df51c6a1eceb97","https://git.kernel.org/stable/c/5a8501d34b261906e4c76ec9da679f2cb4d309ed","https://git.kernel.org/stable/c/d29cda15cab086d82d692de016f7249545d4b6b4","https://git.kernel.org/stable/c/fa3d44424579972cc7c4fac3d9cf227798ebdfa0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49211 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mips: cdmm: Fix refcount leak in mips_cdmm_phys_base The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. | ["https://git.kernel.org/stable/c/4528668ca331f7ce5999b7746657b46db5b3b785","https://git.kernel.org/stable/c/4680c2ac9aabda82acd23ebbd1f900fb6a889cd3","https://git.kernel.org/stable/c/69155dc2e04777aa94207a73a8b10f12b8428a68","https://git.kernel.org/stable/c/721ab4be20d4448dd04c2cc8ed99cd4f3e45f765","https://git.kernel.org/stable/c/ef1728e3cb9e43f38ed10cde705a7ba2b4ad2d35"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49213 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix error handling in ath10k_setup_msa_resources The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path. | ["https://git.kernel.org/stable/c/315772133a4b960859e4f5efe0e738e347188cdc","https://git.kernel.org/stable/c/32939187f254171a5666badc058bc3787fe454af","https://git.kernel.org/stable/c/4ed37d611ea5d222c3ecb3549e4c2d34b8f3c335","https://git.kernel.org/stable/c/74b1d41e1b6410eed5c76d00eedb262036e9eff5","https://git.kernel.org/stable/c/9747a78d5f758a5284751a10aee13c30d02bd5f1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49219 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: fix memory leak during D3hot to D0 transition If 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does not have No_Soft_Reset bit set in its PMCSR config register), then the current PCI state will be saved locally in 'vfio_pci_core_device::pm_save' during D0->D3hot transition and same will be restored back during D3hot->D0 transition. For saving the PCI state locally, pci_store_saved_state() is being used and the pci_load_and_free_saved_state() will free the allocated memory. But for reset related IOCTLs, vfio driver calls PCI reset-related API's which will internally change the PCI power state back to D0. So, when the guest resumes, then it will get the current state as D0 and it will skip the call to vfio_pci_set_power_state() for changing the power state to D0 explicitly. In this case, the memory pointed by 'pm_save' will never be freed. In a malicious sequence, the state changing to D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be run in a loop and it can cause an OOM situation. This patch frees the earlier allocated memory first before overwriting 'pm_save' to prevent the mentioned memory leak. | ["https://git.kernel.org/stable/c/26ddd196e9eb264da8e1bdc4df8a94d62581c8b5","https://git.kernel.org/stable/c/4319f17fb8264ba39352b611dfa913a4d8c1d1a0","https://git.kernel.org/stable/c/c8a1f8bd586ee31020614b8d48b702ece3e2ae44","https://git.kernel.org/stable/c/da426ad86027b849b877d4628b277ffbbd2f5325","https://git.kernel.org/stable/c/eadf88ecf6ac7d6a9f47a76c6055d9a1987a8991"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49221 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dp: populate connector of struct dp_panel DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose and expect DP source return correct checksum. During drm edid read, correct edid checksum is calculated and stored at connector::real_edid_checksum. The problem is struct dp_panel::connector never be assigned, instead the connector is stored in struct msm_dp::connector. When we run compliance testing test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid edid set in struct dp_panel::edid so we'll try to use the connectors real_edid_checksum and hit a NULL pointer dereference error because the connector pointer is never assigned. Changes in V2: -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps() Changes in V3: -- remove unhelpful kernel crash trace commit text -- remove renaming dp_display parameter to dp Changes in V4: -- add more details to commit text Changes in v10: -- group into one series Changes in v11: -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read Signee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> | ["https://git.kernel.org/stable/c/104074ebc0c3f358dd1ee944fbcde92c6e5a21dd","https://git.kernel.org/stable/c/413c62697b61226a236c8b1f5cd64dcf42bcc12f","https://git.kernel.org/stable/c/5e602f5156910c7b19661699896cb6e3fb94fab9","https://git.kernel.org/stable/c/9525b8bcae8b99188990b56484799cf4b1b43786","https://git.kernel.org/stable/c/fbba600f432a360b42452fee79d1fb35d3aa8aeb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49239 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This is similar to commit 64b92de9603f ("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put") | ["https://git.kernel.org/stable/c/1f24716e38220fc9e52e208d20591d2bc9b7f020","https://git.kernel.org/stable/c/2f44eca78cc6d4e1779eb95765ec79e433accab4","https://git.kernel.org/stable/c/9531a631379169d57756b2411178c6238655df88","https://git.kernel.org/stable/c/f3793eeb7b94a5eeed6f5c7a44bce403c6681a12","https://git.kernel.org/stable/c/f8e89d84ea83c51ba3ba97ff154f7aa679326760"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49241 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. This function only calls of_node_put() in the regular path. And it will cause refcount leak in error path. | ["https://git.kernel.org/stable/c/14228225091a0854b1de23e5b4fe8bdeeca9683b","https://git.kernel.org/stable/c/740dc3e846537c3743da98bf106f376023fd085c","https://git.kernel.org/stable/c/90ac679aa6a01841da90ec5a4aaa4b5e0badddf0","https://git.kernel.org/stable/c/f43ad5dc43240289f4cf13c16cc506f4f7087931","https://git.kernel.org/stable/c/f589063b585ac6dd2081bde6c145411cf48d8d92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49312 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix a potential memory leak in r871xu_drv_init() In r871xu_drv_init(), if r8712_init_drv_sw() fails, then the memory allocated by r8712_alloc_io_queue() in r8712_usb_dvobj_init() is not properly released as there is no action will be performed by r8712_usb_dvobj_deinit(). To properly release it, we should call r8712_free_io_queue() in r8712_usb_dvobj_deinit(). Besides, in r871xu_dev_remove(), r8712_usb_dvobj_deinit() will be called by r871x_dev_unload() under condition `padapter->bup` and r8712_free_io_queue() is called by r8712_free_drv_sw(). However, r8712_usb_dvobj_deinit() does not rely on `padapter->bup` and calling r8712_free_io_queue() in r8712_free_drv_sw() is negative for better understading the code. So I move r8712_usb_dvobj_deinit() into r871xu_dev_remove(), and remove r8712_free_io_queue() from r8712_free_drv_sw(). | ["https://git.kernel.org/stable/c/205e039fead72e87ad2838f5e649a4c4834f648b","https://git.kernel.org/stable/c/5a89a92efc342dd7c44b6056da87debc598f9c73","https://git.kernel.org/stable/c/7288ff561de650d4139fab80e9cb0da9b5b32434","https://git.kernel.org/stable/c/8eb42d6d10f8fe509117859defddf9e72b4fa4d0","https://git.kernel.org/stable/c/a2882b8baad068d21c99fb2ab5a85a2bdbd5b834"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49319 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. | ["https://git.kernel.org/stable/c/54c1e0e3bbcab2abe25b2874a43050ae5df87831","https://git.kernel.org/stable/c/54cf47da0c7532d151d76e5d63f5936191698c44","https://git.kernel.org/stable/c/b131fa8c1d2afd05d0b7598621114674289c2fbb","https://git.kernel.org/stable/c/db728a891f9177b044aaca89b678f6b5e24d5cc3","https://git.kernel.org/stable/c/fb0f1c5eb8d60b3e018ba7c87da249b52674ebe6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49376 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix potential NULL pointer dereference If sd_probe() sees an early error before sdkp->device is initialized, sd_zbc_release_disk() is called. This causes a NULL pointer dereference when sd_is_zoned() is called inside that function. Avoid this by removing the call to sd_zbc_release_disk() in sd_probe() error path. This change is safe and does not result in zone information memory leakage because the zone information for a zoned disk is allocated only when sd_revalidate_disk() is called, at which point sdkp->disk_dev is fully set, resulting in sd_disk_release() being called when needed to cleanup a disk zone information using sd_zbc_release_disk(). | ["https://git.kernel.org/stable/c/05fbde3a77a4f1d62e4c4428f384288c1f1a0be5","https://git.kernel.org/stable/c/0fcb0b131cc90c8f523a293d84c58d0c7273c96f","https://git.kernel.org/stable/c/3733439593ad12f7b54ae35c273ea6f15d692de3","https://git.kernel.org/stable/c/78f8e96df06e2d04d82d4071c299b59d28744f47","https://git.kernel.org/stable/c/c1f0187025905e9981000d44a92e159468b561a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49386 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don't release the refcount in error case. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/2e44f21c384503562713b7d3b673c40bed20af3d","https://git.kernel.org/stable/c/5dd89d2fc438457811cbbec07999ce0d80051ff5","https://git.kernel.org/stable/c/78aca10a16f001c9f49f1cc4dadfee8d444bb173","https://git.kernel.org/stable/c/a4b7ef3b159805ba6be061d0cd2403d84b9b0063","https://git.kernel.org/stable/c/f7ba2cc57f404d2d9f26fb85bd3833d35a477829"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49445 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. | ["https://git.kernel.org/stable/c/5376e3d904532e657fd7ca1a9b1ff3d351527b90","https://git.kernel.org/stable/c/5ed0519d425619b435150372cce2ffeec71581fa","https://git.kernel.org/stable/c/e3a1ad8fd0ac11f4fa1260c23b5db71a25473254","https://git.kernel.org/stable/c/f991879762392c19661af5b722578089a12b305f","https://git.kernel.org/stable/c/fb4f022b3ad1f3ff3cafdbc7d51896090ae17701"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49449 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: renesas: rzn1: Fix possible null-ptr-deref in sh_pfc_map_resources() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. | ["https://git.kernel.org/stable/c/01f9e02e0f13df3fd291676dc80054e977be1601","https://git.kernel.org/stable/c/2f661477c2bb8068194dbba9738d05219f111c6e","https://git.kernel.org/stable/c/34c719b8fdfbd0c7c54cae56e6b0f16e9f8bf03e","https://git.kernel.org/stable/c/b646e0cfeb38bf5f1944fd548f1dfa9b129fa00c","https://git.kernel.org/stable/c/c16b59d445135c8026a04e388d8b2762feaa3b3b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49453 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: ti: ti_sci_pm_domains: Check for null return of devm_kcalloc The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code. | ["https://git.kernel.org/stable/c/01ba41a359622ab256ce4d4f8b94c67165ae3daf","https://git.kernel.org/stable/c/05efc4591f80582b6fe53366b70b6a35a42fd255","https://git.kernel.org/stable/c/7cef9274fa1b8506949d74bc45aef072b890824a","https://git.kernel.org/stable/c/ba56291e297d28aa6eb82c5c1964fae2d7594746","https://git.kernel.org/stable/c/c4e188869406b47ac3350920bf165be303cb1c96"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49463 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/imx_sc_thermal: Fix refcount leak in imx_sc_thermal_probe of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/09700c504d8e63faffd2a2235074e8c5d130cb8f","https://git.kernel.org/stable/c/0ec10303c10833c1bcba7a1bde2f297e494d5464","https://git.kernel.org/stable/c/3ade442ea5d3512a3c67984489ab4d8a6fb3b29f","https://git.kernel.org/stable/c/8bbf522a2c51ef939d0e8835e236bfcd252193af","https://git.kernel.org/stable/c/ec0925b731697db7cab5944a3e55d2d58bb3d075"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49473 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: ti: j721e-evm: Fix refcount leak in j721e_soc_probe_* of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/2a3966b950b37a6f10c5f9caee15b4cdcf5a7413","https://git.kernel.org/stable/c/510e879420b410d88c612aecc6ca15dc6fe77473","https://git.kernel.org/stable/c/554df0f70bff1ace6d2df2fcaddbc9b7bd509de2","https://git.kernel.org/stable/c/a34840c4eb3278a7c29c9c57a65ce7541c66f9f2","https://git.kernel.org/stable/c/d748ff8fbb3a5296bddd586445dc692b079cbe3d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49477 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: samsung: Fix refcount leak in aries_audio_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. If extcon_find_edev_by_node() fails, it doesn't call of_node_put() Calling of_node_put() after extcon_find_edev_by_node() to fix this. | ["https://git.kernel.org/stable/c/46d1b310a2d571811c4e08041ce287babb60b86a","https://git.kernel.org/stable/c/70130bde3457d28c02c76b6cacc5d40a72dd6e17","https://git.kernel.org/stable/c/85d899f396622d3034643bf89615a78f9be7c91a","https://git.kernel.org/stable/c/bf4a9b2467b775717d0e9034ad916888e19713a3","https://git.kernel.org/stable/c/cacea459f95be22b3750f3b25b7a1c5897a68206"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49494 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. | ["https://git.kernel.org/stable/c/069af5e27c1b0f7677ef76d8d3102e503ca4f80b","https://git.kernel.org/stable/c/0cfee868b89ffa945f3d535ee5c985cb40c5a0f8","https://git.kernel.org/stable/c/13b60d3dc84b47307669edb66b633b18466014b4","https://git.kernel.org/stable/c/81f1ddffdc22ca5789e33b9d4712914e302090c1","https://git.kernel.org/stable/c/a28ed09dafee20da51eb26452950839633afd824"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49497 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: remove two BUG() from skb_checksum_help() I have a syzbot report that managed to get a crash in skb_checksum_help() If syzbot can trigger these BUG(), it makes sense to replace them with more friendly WARN_ON_ONCE() since skb_checksum_help() can instead return an error code. Note that syzbot will still crash there, until real bug is fixed. | ["https://git.kernel.org/stable/c/312c43e98ed190bd8fd7a71a0addf9539d5b8ab1","https://git.kernel.org/stable/c/6320ae1b5876c30bf98203b6a5abe8b5c45e6a04","https://git.kernel.org/stable/c/b1320c9a4d30ff54b824a8ad6036e0b5fb4c5e73","https://git.kernel.org/stable/c/d5281245f3502e960cb6b89348767b935379cee3","https://git.kernel.org/stable/c/d7ea0d9df2a6265b2b180d17ebc64b38105968fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49502 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: rga: fix possible memory leak in rga_probe rga->m2m_dev needs to be freed when rga_probe fails. | ["https://git.kernel.org/stable/c/1cdc768468c25d6b10ab83ec1efd4a8554532d69","https://git.kernel.org/stable/c/8ddc89437ccefa18279918c19a61fd81527f40b9","https://git.kernel.org/stable/c/a71eb6025305192e646040cd76ccacb5bd48a1b5","https://git.kernel.org/stable/c/b7bbca4d08471bc8404a946bab1aa017dd05199b","https://git.kernel.org/stable/c/eeb4819e94aa69767b9e5591e70c63e8b7c5786a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49523 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath11k: disable spectral scan during spectral deinit When ath11k modules are removed using rmmod with spectral scan enabled, crash is observed. Different crash trace is observed for each crash. Send spectral scan disable WMI command to firmware before cleaning the spectral dbring in the spectral_deinit API to avoid this crash. call trace from one of the crash observed: [ 1252.880802] Unable to handle kernel NULL pointer dereference at virtual address 00000008 [ 1252.882722] pgd = 0f42e886 [ 1252.890955] [00000008] *pgd=00000000 [ 1252.893478] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 1253.093035] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.89 #0 [ 1253.115261] Hardware name: Generic DT based system [ 1253.121149] PC is at ath11k_spectral_process_data+0x434/0x574 [ath11k] [ 1253.125940] LR is at 0x88e31017 [ 1253.132448] pc : [<7f9387b8>] lr : [<88e31017>] psr: a0000193 [ 1253.135488] sp : 80d01bc8 ip : 00000001 fp : 970e0000 [ 1253.141737] r10: 88e31000 r9 : 970ec000 r8 : 00000080 [ 1253.146946] r7 : 94734040 r6 : a0000113 r5 : 00000057 r4 : 00000000 [ 1253.152159] r3 : e18cb694 r2 : 00000217 r1 : 1df1f000 r0 : 00000001 [ 1253.158755] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 1253.165266] Control: 10c0383d Table: 5e71006a DAC: 00000055 [ 1253.172472] Process swapper/0 (pid: 0, stack limit = 0x60870141) [ 1253.458055] [<7f9387b8>] (ath11k_spectral_process_data [ath11k]) from [<7f917fdc>] (ath11k_dbring_buffer_release_event+0x214/0x2e4 [ath11k]) [ 1253.466139] [<7f917fdc>] (ath11k_dbring_buffer_release_event [ath11k]) from [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx+0x1840/0x29cc [ath11k]) [ 1253.478807] [<7f8ea3c4>] (ath11k_wmi_tlv_op_rx [ath11k]) from [<7f8fe868>] (ath11k_htc_rx_completion_handler+0x180/0x4e0 [ath11k]) [ 1253.490699] [<7f8fe868>] (ath11k_htc_rx_completion_handler [ath11k]) from [<7f91308c>] (ath11k_ce_per_engine_service+0x2c4/0x3b4 [ath11k]) [ 1253.502386] [<7f91308c>] (ath11k_ce_per_engine_service [ath11k]) from [<7f9a4198>] (ath11k_pci_ce_tasklet+0x28/0x80 [ath11k_pci]) [ 1253.514811] [<7f9a4198>] (ath11k_pci_ce_tasklet [ath11k_pci]) from [<8032227c>] (tasklet_action_common.constprop.2+0x64/0xe8) [ 1253.526476] [<8032227c>] (tasklet_action_common.constprop.2) from [<803021e8>] (__do_softirq+0x130/0x2d0) [ 1253.537756] [<803021e8>] (__do_softirq) from [<80322610>] (irq_exit+0xcc/0xe8) [ 1253.547304] [<80322610>] (irq_exit) from [<8036a4a4>] (__handle_domain_irq+0x60/0xb4) [ 1253.554428] [<8036a4a4>] (__handle_domain_irq) from [<805eb348>] (gic_handle_irq+0x4c/0x90) [ 1253.562321] [<805eb348>] (gic_handle_irq) from [<80301a78>] (__irq_svc+0x58/0x8c) Tested-on: QCN6122 hw1.0 AHB WLAN.HK.2.6.0.1-00851-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/161c64de239c7018e0295e7e0520a19f00aa32dc","https://git.kernel.org/stable/c/451b9076903a057b7b8d5b24dc84b3e436a1c743","https://git.kernel.org/stable/c/4b9c54caef58d2b55074710952cda70540722c01","https://git.kernel.org/stable/c/60afa4f4e1350c876d8a061182a70c224de275dd","https://git.kernel.org/stable/c/8f15e67af9bec5a69e815e0230a70cffddae371a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49549 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails In mce_threshold_create_device(), if threshold_create_bank() fails, the previously allocated threshold banks array @bp will be leaked because the call to mce_threshold_remove_device() will not free it. This happens because mce_threshold_remove_device() fetches the pointer through the threshold_banks per-CPU variable but bp is written there only after the bank creation is successful, and not before, when threshold_create_bank() fails. Add a helper which unwinds all the bank creation work previously done and pass into it the previously allocated threshold banks array for freeing. [ bp: Massage. ] | ["https://git.kernel.org/stable/c/396b8e7ab2a99ddac57d3522b3da5e58cb608d37","https://git.kernel.org/stable/c/9708f1956eeb70c86943e0bc62fa3b0101b59616","https://git.kernel.org/stable/c/b4acb8e7f1594607bc9017ef0aacb40b24a003d6","https://git.kernel.org/stable/c/cc0dd4456f9573bf8af9b4d8754433918e809e1e","https://git.kernel.org/stable/c/e5f28623ceb103e13fc3d7bd45edf9818b227fd0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49569 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: bcm2835: bcm2835_spi_handle_err(): fix NULL pointer deref for non DMA transfers In case a IRQ based transfer times out the bcm2835_spi_handle_err() function is called. Since commit 1513ceee70f2 ("spi: bcm2835: Drop dma_pending flag") the TX and RX DMA transfers are unconditionally canceled, leading to NULL pointer derefs if ctlr->dma_tx or ctlr->dma_rx are not set. Fix the NULL pointer deref by checking that ctlr->dma_tx and ctlr->dma_rx are valid pointers before accessing them. | ["https://git.kernel.org/stable/c/49ffa473218012e765682343de2052eb4c1f06a7","https://git.kernel.org/stable/c/4ceaa684459d414992acbefb4e4c31f2dfc50641","https://git.kernel.org/stable/c/58466e05390043d2805685c70f55f3f59711bdf2","https://git.kernel.org/stable/c/684896e675edd8b669fd3e9f547c5038222d85bc","https://git.kernel.org/stable/c/76668d2a2f367d25ff448e6d7087406af7d7bb2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49583 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iavf: Fix handling of dummy receive descriptors Fix memory leak caused by not handling dummy receive descriptor properly. iavf_get_rx_buffer now sets the rx_buffer return value for dummy receive descriptors. Without this patch, when the hardware writes a dummy descriptor, iavf would not free the page allocated for the previous receive buffer. This is an unlikely event but can still happen. [Jesse: massaged commit message] | ["https://git.kernel.org/stable/c/2918419c06088f6709ceb543feb01752779ade4c","https://git.kernel.org/stable/c/6edb818732fc05fda495f5b3a749bd1cee01398b","https://git.kernel.org/stable/c/a9f49e0060301a9bfebeca76739158d0cf91cdf6","https://git.kernel.org/stable/c/c6af94324911ef0846af1a5ce5e049ca736db34b","https://git.kernel.org/stable/c/d88d59faf4e6f9cc4767664206afdb999b10ec77"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49643 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ima: Fix a potential integer overflow in ima_appraise_measurement When the ima-modsig is enabled, the rc passed to evm_verifyxattr() may be negative, which may cause the integer overflow problem. | ["https://git.kernel.org/stable/c/388f3df7c3c8b7f2a32b9ae0a9b2f9f6ad3b1b77","https://git.kernel.org/stable/c/640cea4c2839a821adfbb703b590a5928abe9286","https://git.kernel.org/stable/c/831e190175f10652be93b08436cc7bf2e62e4bb6","https://git.kernel.org/stable/c/c8d5d81940938b5f6c0f495ca9538e7740416f30","https://git.kernel.org/stable/c/d2ee2cfc4aa85ff6a2a3b198a3a524ec54e3d999"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49644 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector() If drm_connector_init fails, intel_connector_free will be called to take care of proper free. So it is necessary to drop the refcount of port before intel_connector_free. (cherry picked from commit cea9ed611e85d36a05db52b6457bf584b7d969e2) | ["https://git.kernel.org/stable/c/505114dda5bbfd07f4ce9a2df5b7d8ef5f2a1218","https://git.kernel.org/stable/c/592f3bad00b7e2a95a6fb7a4f9e742c061c9c3c1","https://git.kernel.org/stable/c/72f231b9a88abcfac9f5ddaa1a0aacb3f9f87ba5","https://git.kernel.org/stable/c/85144df9ff4652816448369de76897c57cbb1b93","https://git.kernel.org/stable/c/a91522b4279bebb098106a19b91f82b9c3213be9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49668 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: exynos-ppmu: Fix refcount leak in of_get_devfreq_events of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. This function only calls of_node_put() in normal path, missing it in error paths. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/01121e39ef537289926ae6f5374dce92c796d863","https://git.kernel.org/stable/c/194781229d4cbc804b8ded13156eb8addce87d6c","https://git.kernel.org/stable/c/bdecd912e99acfd61507f1720d3f4eed1b3418d8","https://git.kernel.org/stable/c/e65027fdebbacd40595e96ef7b5d2418f71bddf2","https://git.kernel.org/stable/c/f44b799603a9b5d2e375b0b2d54dd0b791eddfc2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49670 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: linux/dim: Fix divide by 0 in RDMA DIM Fix a divide 0 error in rdma_dim_stats_compare() when prev->cpe_ratio == 0. CallTrace: Hardware name: H3C R4900 G3/RS33M2C9S, BIOS 2.00.37P21 03/12/2020 task: ffff880194b78000 task.stack: ffffc90006714000 RIP: 0010:backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: 0018:ffff880c10e83ec0 EFLAGS: 00010202 RAX: 0000000000002710 RBX: ffff88096cd7f780 RCX: 0000000000000064 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000001 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 000000001d7c6c09 R13: ffff88096cd7f780 R14: ffff880b174fe800 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff880c10e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000a0965b00 CR3: 000000000200a003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> ib_poll_handler+0x43/0x80 [ib_core] irq_poll_softirq+0xae/0x110 __do_softirq+0xd1/0x28c irq_exit+0xde/0xf0 do_IRQ+0x54/0xe0 common_interrupt+0x8f/0x8f </IRQ> ? cpuidle_enter_state+0xd9/0x2a0 ? cpuidle_enter_state+0xc7/0x2a0 ? do_idle+0x170/0x1d0 ? cpu_startup_entry+0x6f/0x80 ? start_secondary+0x1b9/0x210 ? secondary_startup_64+0xa5/0xb0 Code: 0f 87 e1 00 00 00 8b 4c 24 14 44 8b 43 14 89 c8 4d 63 c8 44 29 c0 99 31 d0 29 d0 31 d2 48 98 48 8d 04 80 48 8d 04 80 48 c1 e0 02 <49> f7 f1 48 83 f8 0a 0f 86 c1 00 00 00 44 39 c1 7f 10 48 89 df RIP: backport_rdma_dim+0x10e/0x240 [mlx_compat] RSP: ffff880c10e83ec0 | ["https://git.kernel.org/stable/c/0b6e0eb5c45e79e9095de2498cc0ca5ec563fc5e","https://git.kernel.org/stable/c/0fe3dbbefb74a8575f61d7801b08dbc50523d60d","https://git.kernel.org/stable/c/5af106f8e072aebd88b95e164a08fa320651a99a","https://git.kernel.org/stable/c/7c1963391af51ee322378d1b2849c60e9037f069","https://git.kernel.org/stable/c/fae2a9fb1eaf348ad8732f90d42ebbb971bd7e95"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49693 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf of_graph_get_remote_node() returns remote device node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Patchwork: https://patchwork.freedesktop.org/patch/488473/ | ["https://git.kernel.org/stable/c/3c39a17197733bc37786ed68c83267c2f491840b","https://git.kernel.org/stable/c/b9cc4598607cb7f7eae5c75fc1e3209cd52ff5e0","https://git.kernel.org/stable/c/d1592d3e362cc59b29f15019707b16c695d70ca3","https://git.kernel.org/stable/c/d16a4339825e64f9ddcdff5277982d640bae933b","https://git.kernel.org/stable/c/d607da76fd2b1cf1d377af9d9b7c6f8fecbb0e1d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49716 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Fix error handling in gic_populate_ppi_partitions of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. When kcalloc fails, it missing of_node_put() and results in refcount leak. Fix this by goto out_put_node label. | ["https://git.kernel.org/stable/c/0b325d993995a321f6ab4e6c51f0504ec092bf5b","https://git.kernel.org/stable/c/58e67c81e229351027d28c610638378606e33a08","https://git.kernel.org/stable/c/7c9dd9d23f26dabcfb14148b9acdfba540418b19","https://git.kernel.org/stable/c/c83c34c57798fc41faefcf078be78683db2f4beb","https://git.kernel.org/stable/c/ec8401a429ffee34ccf38cebf3443f8d5ae6cb0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48862 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vhost: fix hung thread due to erroneous iotlb entries In vhost_iotlb_add_range_ctx(), range size can overflow to 0 when start is 0 and last is ULONG_MAX. One instance where it can happen is when userspace sends an IOTLB message with iova=size=uaddr=0 (vhost_process_iotlb_msg). So, an entry with size = 0, start = 0, last = ULONG_MAX ends up in the iotlb. Next time a packet is sent, iotlb_access_ok() loops indefinitely due to that erroneous entry. Call Trace: <TASK> iotlb_access_ok+0x21b/0x3e0 drivers/vhost/vhost.c:1340 vq_meta_prefetch+0xbc/0x280 drivers/vhost/vhost.c:1366 vhost_transport_do_send_pkt+0xe0/0xfd0 drivers/vhost/vsock.c:104 vhost_worker+0x23d/0x3d0 drivers/vhost/vhost.c:372 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK> Reported by syzbot at: https://syzkaller.appspot.com/bug?extid=0abd373e2e50d704db87 To fix this, do two things: 1. Return -EINVAL in vhost_chr_write_iter() when userspace asks to map a range with size 0. 2. Fix vhost_iotlb_add_range_ctx() to handle the range [0, ULONG_MAX] by splitting it into two entries. | ["https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad","https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667","https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1","https://git.kernel.org/stable/c/d9a747e6b6561280bf1791bb24c5e9e082193dad","https://git.kernel.org/stable/c/e2ae38cf3d91837a493cb2093c87700ff3cbe667","https://git.kernel.org/stable/c/f8d88e86e90ea1002226d7ac2430152bfea003d1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0394 | Medium | fixed |
|
A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230302-0005/","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb3e9864cdbe35ff6378966660edbcbac955fe17","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230302-0005/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52462 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper. | ["https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef","https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036","https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf","https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174","https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae","https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104","https://git.kernel.org/stable/c/2757f17972d87773b3677777f5682510f13c66ef","https://git.kernel.org/stable/c/40617d45ea05535105e202a8a819e388a2b1f036","https://git.kernel.org/stable/c/67e6707f07354ed1acb4e65552e97c60cf9d69cf","https://git.kernel.org/stable/c/8dc15b0670594543c356567a1a45b0182ec63174","https://git.kernel.org/stable/c/ab125ed3ec1c10ccc36bc98c7a4256ad114a3dae","https://git.kernel.org/stable/c/fc3e3c50a0a4cac1463967c110686189e4a59104","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49108 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: mediatek: Fix memory leaks on probe Handle the error branches to free memory where required. Addresses-Coverity-ID: 1491825 ("Resource leak") | ["https://git.kernel.org/stable/c/02742d1d5c95cff8b6e9379aae4ab12674f7265d","https://git.kernel.org/stable/c/7a688c91d3fd54c53e7a9edd6052cdae98dd99d8","https://git.kernel.org/stable/c/c6a0b413398588fc2d8b174a79ea715b66413fca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49342 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: bgmac: Fix refcount leak in bcma_mdio_mii_register of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/7fb1fe7d9a167205413f1de8db9f7d0f82c78286","https://git.kernel.org/stable/c/b51996e35bbfcc7a27d94dfeed5cc2429b2c0df4","https://git.kernel.org/stable/c/b8d91399775c55162073bb2aca061ec42e3d4bc1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49476 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix kernel crash at mt7921_pci_remove The crash log shown it is possible that mt7921_irq_handler is called while devm_free_irq is being handled so mt76_free_device need to be postponed until devm_free_irq is completed to solve the crash we free the mt76 device too early. [ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 9299.339705] #PF: supervisor read access in kernel mode [ 9299.339735] #PF: error_code(0x0000) - not-present page [ 9299.339768] PGD 0 P4D 0 [ 9299.339786] Oops: 0000 [#1] SMP PTI [ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1 [ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022 [ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e] [ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082 [ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5 [ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020 [ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011 [ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080 [ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228 [ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000 [ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0 [ 9299.340432] PKRU: 55555554 [ 9299.340449] Call Trace: [ 9299.340467] <TASK> [ 9299.340485] __free_irq+0x221/0x350 [ 9299.340527] free_irq+0x30/0x70 [ 9299.340553] devm_free_irq+0x55/0x80 [ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e] [ 9299.340616] pci_device_remove+0x3b/0xa0 [ 9299.340651] __device_release_driver+0x17a/0x240 [ 9299.340686] device_driver_detach+0x3c/0xa0 [ 9299.340714] unbind_store+0x113/0x130 [ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0 [ 9299.340775] new_sync_write+0x15c/0x1f0 [ 9299.340806] vfs_write+0x1d2/0x270 [ 9299.340831] ksys_write+0x67/0xe0 [ 9299.340857] do_syscall_64+0x3b/0x90 [ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/09693f5b636fb3f6dd56fd943226fc1bbc600b51","https://git.kernel.org/stable/c/677e669973bf5460705bc65033445ea9f6615999","https://git.kernel.org/stable/c/ad483ed9dd5193a54293269c852a29051813b7bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49563 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for RSA Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. | ["https://git.kernel.org/stable/c/4d6d2adce08788b7667a6e58002682ea1bbf6a79","https://git.kernel.org/stable/c/9714061423b8b24b8afb31b8eb4df977c63f19c4","https://git.kernel.org/stable/c/f993321e50ba7a8ba4f5b19939e1772a921a1c42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49564 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - add param check for DH Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer. | ["https://git.kernel.org/stable/c/2acbb8771f6ac82422886e63832ee7a0f4b1635b","https://git.kernel.org/stable/c/76c9216833e7c20a67c987cf89719a3f01666aaa","https://git.kernel.org/stable/c/e7f979ed51f96495328157df663c835b17db1e30"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49566 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: qat - fix memory leak in RSA When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released. Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context. | ["https://git.kernel.org/stable/c/0f967fdc09955221a1951a279481b0bf4d359941","https://git.kernel.org/stable/c/80a52e1ee7757b742f96bfb0d58f0c14eb6583d0","https://git.kernel.org/stable/c/a843925e0287eebb4aa808666bf22c664dfe4c53"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49570 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: gpio-xilinx: Fix integer overflow Current implementation is not able to configure more than 32 pins due to incorrect data type. So type casting with unsigned long to avoid it. | ["https://git.kernel.org/stable/c/32c094a09d5829ad9b02cdf667569aefa8de0ea6","https://git.kernel.org/stable/c/6f16a5390640807dde420ee5ccbc4c95577aea6a","https://git.kernel.org/stable/c/e129e5486b981d324057e6986059f852658b0d00"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49591 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: microchip: ksz_common: Fix refcount leak bug In ksz_switch_register(), we should call of_node_put() for the reference returned by of_get_child_by_name() which has increased the refcount. | ["https://git.kernel.org/stable/c/4165e02716518bbbe9c9104b39530d40928bc7ce","https://git.kernel.org/stable/c/88ec2ff42da3ac93b2437dc52fe25cd4372148e6","https://git.kernel.org/stable/c/a14bd7475452c51835dd5a0cee4c8fa48dd0b539"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49615 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: rt711-sdca: fix kernel NULL pointer dereference when IO error The initial settings will be written before the codec probe function. But, the rt711->component doesn't be assigned yet. If IO error happened during initial settings operations, it will cause the kernel panic. This patch changed component->dev to slave->dev to fix this issue. | ["https://git.kernel.org/stable/c/1df793d479bef546569fc2e409ff8bb3f0fb8e99","https://git.kernel.org/stable/c/269be8b2907378adf72d7347cfa43ef230351a06","https://git.kernel.org/stable/c/7bb71133cae88d3003a3490b97864af76533072b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49703 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: ibmvfc: Store vhost pointer during subcrq allocation Currently the back pointer from a queue to the vhost adapter isn't set until after subcrq interrupt registration. The value is available when a queue is first allocated and can/should be also set for primary and async queues as well as subcrqs. This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS interrupt controller where a pending subcrq interrupt from the previous kernel can be replayed immediately upon IRQ registration resulting in dereference of a garbage backpointer in ibmvfc_interrupt_scsi(). Kernel attempted to read user page (58) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000058 Faulting instruction address: 0xc008000003216a08 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc] LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 Call Trace: [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable) [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270 [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188 [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310 [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80 [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0 [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130 [c000000014622f60] [0000000020000000] 0x20000000 [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0 [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0 [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170 [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0 [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0 [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230 [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc] [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc] [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc] [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc] [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc] | ["https://git.kernel.org/stable/c/6d38e3b614ded59da8b95377a98df969a5a5627a","https://git.kernel.org/stable/c/8540f66196ca35b7b5e902932571c18b9fde0cd1","https://git.kernel.org/stable/c/aeaadcde1a60138bceb65de3cdaeec78170b4459"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49704 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_get_link we check for protocol version later than required, after a fid has been obtained. Just move the version check earlier. | ["https://git.kernel.org/stable/c/e5690f263208c5abce7451370b7786eb25b405eb","https://git.kernel.org/stable/c/e7b6d622bd812013eb39c8f4cd65b7ee8ede1e02","https://git.kernel.org/stable/c/f0126bcaee81dabc1926012126aa74caa03a4c6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49705 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl We need to release directory fid if we fail halfway through open This fixes fid leaking with xfstests generic 531 | ["https://git.kernel.org/stable/c/22832ac3eb5be3f7168816a76b64c1284e12eb3c","https://git.kernel.org/stable/c/8bc5412ba1a45edfd1e451874c483c26a097af2b","https://git.kernel.org/stable/c/beca774fc51a9ba8abbc869cf0c3d965ff17cd24"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49714 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: irqchip/realtek-rtl: Fix refcount leak in map_interrupts of_find_node_by_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in error path. Call of_node_put() directly after of_property_read_u32() to cover both normal path and error path. | ["https://git.kernel.org/stable/c/e85b1b797de0e7a271b906291ce28245822820b8","https://git.kernel.org/stable/c/eff4780f83d0ae3e5b6c02ff5d999dc4c1c5c8ce","https://git.kernel.org/stable/c/f6d6223df0666fbc054e3a8c6ac14eb0af37c286"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58089 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix double accounting race when btrfs_run_delalloc_range() failed [BUG] When running btrfs with block size (4K) smaller than page size (64K, aarch64), there is a very high chance to crash the kernel at generic/750, with the following messages: (before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b [CAUSE] The above warning is triggered immediately after the delalloc range failure, this happens in the following sequence: - Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size) - Enter extent_writepage() for page 1536K - Enter run_delalloc_nocow() with locke ---truncated--- | ["https://git.kernel.org/stable/c/0283ee1912c8e243c931f4ee5b3672e954fe0384","https://git.kernel.org/stable/c/21333148b5c9e52f41fafcedec3810b56a5e0e40","https://git.kernel.org/stable/c/72dad8e377afa50435940adfb697e070d3556670"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize() If migration succeeded, we called folio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from the old to the new folio. This will set memcg_data of the old folio to 0. Similarly, if migration failed, memcg_data of the dst folio is left unset. If we call folio_putback_lru() on such folios (memcg_data == 0), we will add the folio to be freed to the LRU, making memcg code unhappy. Running the hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] <TASK> [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80 Likely, nothing else goes wrong: putting the last folio reference will remove the folio from the LRU again. So besides memcg complaining, adding the folio to be freed to the LRU is just an unnecessary step. The new flow resembles what we have in migrate_folio_move(): add the dst to the lru, rem ---truncated--- | ["https://git.kernel.org/stable/c/069dd21ea8262204f94737878389c2815a054a9e","https://git.kernel.org/stable/c/3f9240d59e9a95d19f06120bfd1d0e681c6c0ac7","https://git.kernel.org/stable/c/41cddf83d8b00f29fd105e7a0777366edc69a5cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56647 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: Fix icmp host relookup triggering ip_rt_bug arp link failure may trigger ip_rt_bug while xfrm enabled, call trace is: WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20 Modules linked in: CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ip_rt_bug+0x14/0x20 Call Trace: <IRQ> ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90 The script below reproduces this scenario: ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmp ip l a veth1 type veth ip a a 192.168.141.111/24 dev veth0 ip l s veth0 up ping 192.168.141.155 -c 1 icmp_route_lookup() create input routes for locally generated packets while xfrm relookup ICMP traffic.Then it will set input route (dst->out = ip_rt_bug) to skb for DESTUNREACH. For ICMP err triggered by locally generated packets, dst->dev of output route is loopback. Generally, xfrm relookup verification is not required on loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1). Skip icmp relookup for locally generated packets to fix it. | ["https://git.kernel.org/stable/c/9545011e7b2a8fc0cbd6e387a09f12cd41d7d82f","https://git.kernel.org/stable/c/c44daa7e3c73229f7ac74985acb8c7fb909c4e0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47654 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: samples/landlock: Fix path_list memory leak Clang static analysis reports this error sandboxer.c:134:8: warning: Potential leak of memory pointed to by 'path_list' ret = 0; ^ path_list is allocated in parse_path() but never freed. | ["https://git.kernel.org/stable/c/017196730299ccd6eed24bbfabed8af4ffd81530","https://git.kernel.org/stable/c/20fbf100f84b9aeb9c91421abe1927bc152bc32b","https://git.kernel.org/stable/c/49b0d8bf05809df5f87e5c03e26d74bdfdab4571","https://git.kernel.org/stable/c/66b513b7c64a7290c1fbb88e657f7cece992e131"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47657 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free() If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it happened in the bug report by syzbot), virtio_gpu_array_put_free() could be called with objs equal to NULL. Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise return from the function. | ["https://git.kernel.org/stable/c/6b79f96f4a23846516e5e6e4dd37fc06f43a60dd","https://git.kernel.org/stable/c/abc9ad36df16e27ac1c665085157f1a082d39bac","https://git.kernel.org/stable/c/ac92b474eeeed75b8660374ba1d129a121c09da8","https://git.kernel.org/stable/c/b094fece3810c71ceee6f0921676cb65d4e68c5a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47660 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()' All error handling paths lead to 'out' where many resources are freed. Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->one_page_buf' (at least) will leak. | ["https://git.kernel.org/stable/c/2c97519ed6b4239594c58ddacf3d0d576cf070cc","https://git.kernel.org/stable/c/bc4a1d384a04c6dba9312e1421a9f9f7c03339a4","https://git.kernel.org/stable/c/d8be98ab88250dc12a98efdb703792a537b0eac3","https://git.kernel.org/stable/c/e589f9b7078e1c0191613cd736f598e81d2390de"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49046 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: dev: check return value when calling dev_set_name() If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. | ["https://git.kernel.org/stable/c/2e539b17d4cbe5fb8b5152dd9a6e4a8828f97db2","https://git.kernel.org/stable/c/2f345bb14ad4744950499ff222e2899209297afa","https://git.kernel.org/stable/c/993eb48fa199b5f476df8204e652eff63dd19361","https://git.kernel.org/stable/c/c74d77a2d07744147d734138acd6ce9dba715e5d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49065 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix the svc_deferred_event trace class Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address. Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is: event svc_defer_recv has unsafe dereference of argument 1 A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check. Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels. In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window. | ["https://git.kernel.org/stable/c/4d5004451ab2218eab94a30e1841462c9316ba19","https://git.kernel.org/stable/c/726ae7300fcc25fefa46d188cc07eb16dc908f9e","https://git.kernel.org/stable/c/85ee17ca21cf92989e8c923e3ea4514c291e9d38","https://git.kernel.org/stable/c/c2456f470eea3bd06574d988bf6089e7c3f4c5cc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49071 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/panel: ili9341: fix optional regulator handling If the optional regulator lookup fails, reset the pointer to NULL. Other functions such as mipi_dbi_poweron_reset_conditional() only do a NULL pointer check and will otherwise dereference the error pointer. | ["https://git.kernel.org/stable/c/28dc1503a9d36654f9c61adb2915682515a30f71","https://git.kernel.org/stable/c/4ea189854b1e625ed5ec80d30147870f984db44c","https://git.kernel.org/stable/c/d14eb80e27795b7b20060f7b151cdfe39722a813","https://git.kernel.org/stable/c/e3d982c111a6c033671dd6084b07f62fbf50f76f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49096 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sfc: add missing xdp queue reinitialization After rx/tx ring buffer size is changed, kernel panic occurs when it acts XDP_TX or XDP_REDIRECT. When tx/rx ring buffer size is changed(ethtool -G), sfc driver reallocates and reinitializes rx and tx queues and their buffer (tx_queue->buffer). But it misses reinitializing xdp queues(efx->xdp_tx_queues). So, while it is acting XDP_TX or XDP_REDIRECT, it uses the uninitialized tx_queue->buffer. A new function efx_set_xdp_channels() is separated from efx_set_channels() to handle only xdp queues. Splat looks like: BUG: kernel NULL pointer dereference, address: 000000000000002a #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#4] PREEMPT SMP NOPTI RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297 RIP: 0010:efx_tx_map_chunk+0x54/0x90 [sfc] RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0 RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0 FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0 RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297 PKRU: 55555554 RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700 RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700 FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0 PKRU: 55555554 Call Trace: <IRQ> efx_xdp_tx_buffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] __efx_rx_packet+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_rx_packet+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efx_ef10_ev_process+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] ? enqueue_task_fair+0x95/0x550 efx_poll+0xc4/0x360 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] | ["https://git.kernel.org/stable/c/059a47f1da93811d37533556d67e72f2261b1127","https://git.kernel.org/stable/c/b8c46bc358d84701e7f7ffa054037db25f25da0e","https://git.kernel.org/stable/c/dcc85e1593686e42c6749ef3d356db34759d59e8","https://git.kernel.org/stable/c/ed7a824fda8732578d1014fad1f7fb0363705090"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49102 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: habanalabs: fix possible memory leak in MMU DR fini This patch fixes what seems to be copy paste error. We will have a memory leak if the host-resident shadow is NULL (which will likely happen as the DR and HR are not dependent). | ["https://git.kernel.org/stable/c/12e49aefda2e04b07604f13e03f40027cbeb0dc6","https://git.kernel.org/stable/c/30058d3a83cfe8c6aacbfe5ab13c01dd0c1799e3","https://git.kernel.org/stable/c/6d421fb7a9eddd8ce0a05641a3db97283fe20699","https://git.kernel.org/stable/c/eb85eec858c1a5c11d3a0bff403f6440b05b40dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49106 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: vchiq_arm: Avoid NULL ptr deref in vchiq_dump_platform_instances vchiq_get_state() can return a NULL pointer. So handle this cases and avoid a NULL pointer derefence in vchiq_dump_platform_instances. | ["https://git.kernel.org/stable/c/176df12b38c70b0a45e6392a0ee5bc83489dfc29","https://git.kernel.org/stable/c/4627250cabaa80278d3ab01ad107893cea83799f","https://git.kernel.org/stable/c/51e5e5c34c22c0bfec0808d8c33e0b2fcf4c7c89","https://git.kernel.org/stable/c/aa899e686d442c63d50f4d369cc02dbbf0941cb0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49126 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: mpi3mr: Fix memory leaks Fix memory leaks related to operational reply queue's memory segments which are not getting freed while unloading the driver. | ["https://git.kernel.org/stable/c/27fc9e90171ab0a94a411f3fdb3522ef5acb9537","https://git.kernel.org/stable/c/5d76a88b8536d75ff5362e232097e85946b8aadf","https://git.kernel.org/stable/c/71c7ac65a084ae7d387c3c1d02d59edfdecb009f","https://git.kernel.org/stable/c/d44b5fefb22e139408ae12b864da1ecb9ad9d1d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49128 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: Add missing pm_runtime_put_sync pm_runtime_get_sync() will increase the rumtime PM counter even when it returns an error. Thus a pairing decrement is needed to prevent refcount leak. Fix this by replacing this API with pm_runtime_resume_and_get(), which will not change the runtime PM counter on error. Besides, a matching decrement is needed on the error handling path to keep the counter balanced. | ["https://git.kernel.org/stable/c/46f47807738441e354873546dde0b000106c068a","https://git.kernel.org/stable/c/792533e54cd6e89191798ccd1abd590c62b9077e","https://git.kernel.org/stable/c/9df80dc738926a2ea4bd1ce5993c3d0f4b0e855c","https://git.kernel.org/stable/c/ff13c90d7f7ab606b37be6d15140d19013d6736c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49135 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak [why] Resource release is needed on the error handling path to prevent memory leak. [how] Fix this by adding kfree on the error handling path. | ["https://git.kernel.org/stable/c/3ce1497add6d17b48cc9df65095bd20202d93994","https://git.kernel.org/stable/c/5d5c6dba2b43e28845d7d7ed32a36802329a5f52","https://git.kernel.org/stable/c/7e10369c72db7a0e2f77b2e306aadc07aef6b07a","https://git.kernel.org/stable/c/9d0bef3cc22cf250278ed45b829f062a00af9e27"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49183 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix ref leak when switching zones When switching zones or network namespaces without doing a ct clear in between, it is now leaking a reference to the old ct entry. That's because tcf_ct_skb_nfct_cached() returns false and tcf_ct_flow_table_lookup() may simply overwrite it. The fix is to, as the ct entry is not reusable, free it already at tcf_ct_skb_nfct_cached(). | ["https://git.kernel.org/stable/c/4bb42d73def9411e5cad885b9811987d72431df1","https://git.kernel.org/stable/c/b24793a37d91aacad7cb9893b226a7924a89636a","https://git.kernel.org/stable/c/bcb74e132a76ce0502bb33d5b65533a4ed72d159","https://git.kernel.org/stable/c/bcbf4e5c3b5b373cd61528392dd1ec8e9c0fd33d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49184 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: sparx5: switchdev: fix possible NULL pointer dereference As the possible failure of the allocation, devm_kzalloc() may return NULL pointer. Therefore, it should be better to check the 'db' in order to prevent the dereference of NULL pointer. | ["https://git.kernel.org/stable/c/0906f3a3df07835e37077d8971aac65347f2ed57","https://git.kernel.org/stable/c/b375ea083fa649092cd016ac1f89a2d1fd8f8e8b","https://git.kernel.org/stable/c/c346791877e6ce923bb21e34b30c6f99326aa5a8","https://git.kernel.org/stable/c/e7e1fff76c4c57688dc7d53a3b6212182d5628d0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49187 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: Fix clk_hw_get_clk() when dev is NULL Any registered clk_core structure can have a NULL pointer in its dev field. While never actually documented, this is evidenced by the wide usage of clk_register and clk_hw_register with a NULL device pointer, and the fact that the core of_clk_hw_register() function also passes a NULL device pointer. A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that case will result in a NULL pointer derefence when it calls dev_name() on that NULL device pointer. Add a test for this case and use NULL as the dev_id if the device pointer is NULL. | ["https://git.kernel.org/stable/c/0c1b56df451716ba207bbf59f303473643eee4fd","https://git.kernel.org/stable/c/23f89fe005b105f0dcc55034c13eb89f9b570fac","https://git.kernel.org/stable/c/4be3e4c05d8dd1b83b75652cad88c9e752ec7054","https://git.kernel.org/stable/c/d183f20cf5a7b546d4108e796b98210ceb317579"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49207 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in sk_psock_queue_msg If tcp_bpf_sendmsg is running during a tear down operation we may enqueue data on the ingress msg queue while tear down is trying to free it. sk1 (redirect sk2) sk2 ------------------- --------------- tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock() While drop_sk_msg(), the msg has charged memory form sk by sk_mem_charge and has sg pages need to put. To fix we use sk_msg_free() and then kfee() msg. This issue can cause the following info: WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0 Call Trace: <IRQ> inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 </IRQ> WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0 Call Trace: <TASK> __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> | ["https://git.kernel.org/stable/c/03948ed6553960db62f1c33bec29e64d7c191a3f","https://git.kernel.org/stable/c/4dd2e947d3be13a4de3b3028859b9a6497266bcf","https://git.kernel.org/stable/c/938d3480b92fa5e454b7734294f12a7b75126f09","https://git.kernel.org/stable/c/ef9785f429794567792561a584901faa9291d3ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49208 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Prevent some integer underflows My static checker complains that: drivers/infiniband/hw/irdma/ctrl.c:3605 irdma_sc_ceq_init() warn: can subtract underflow 'info->dev->hmc_fpm_misc.max_ceqs'? It appears that "info->dev->hmc_fpm_misc.max_ceqs" comes from the firmware in irdma_sc_parse_fpm_query_buf() so, yes, there is a chance that it could be zero. Even if we trust the firmware, it's easy enough to change the condition just as a hardenning measure. | ["https://git.kernel.org/stable/c/6f6dbb819dfc1a35bcb8b709b5c83a3ea8beff75","https://git.kernel.org/stable/c/7340c3675d7ac946f4019b84cd7c64ed542dfe4c","https://git.kernel.org/stable/c/d52dab6e03550f9c97121b0c11c0a3ed78ee76a4","https://git.kernel.org/stable/c/f21056f15bbeacab7b4b87af232f5599d1f2bff1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49273 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtc: pl031: fix rtc features null pointer dereference When there is no interrupt line, rtc alarm feature is disabled. The clearing of the alarm feature bit was being done prior to allocations of ldata->rtc device, resulting in a null pointer dereference. Clear RTC_FEATURE_ALARM after the rtc device is allocated. | ["https://git.kernel.org/stable/c/1b915703964f7e636961df04c540261dc55c6c70","https://git.kernel.org/stable/c/cd2722e411e8ab7e5ae41102f6925fa13dffdac5","https://git.kernel.org/stable/c/d274ce4a3dfd0b9a292667535578359b865765cb","https://git.kernel.org/stable/c/ea6af39f3da50c86367a71eb3cc674ade3ed244c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49284 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: coresight: syscfg: Fix memleak on registration failure in cscfg_create_device device_register() calls device_initialize(), according to doc of device_initialize: Use put_device() to give up your reference instead of freeing * @dev directly once you have called this function. To prevent potential memleak, use put_device() for error handling. | ["https://git.kernel.org/stable/c/412225b32986d5b11c3c1ad9234c50a3f5c52c76","https://git.kernel.org/stable/c/a529af1f5a5c096f3e18f0d5a32cfcc3d82df1ec","https://git.kernel.org/stable/c/c61e2fc87f24cae4701f352fe9ecd4c5c143106c","https://git.kernel.org/stable/c/cfa5dbcdd7aece76f3415284569f2f384aff0253"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49294 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check if modulo is 0 before dividing. [How & Why] If a value of 0 is read, then this will cause a divide-by-0 panic. | ["https://git.kernel.org/stable/c/07efce8269a038c37814eb656b4de14aa3015fc6","https://git.kernel.org/stable/c/10ef82d6e0af5536ec64770c07f6bbabfdd6977c","https://git.kernel.org/stable/c/49947b906a6bd9668eaf4f9cf691973c25c26955","https://git.kernel.org/stable/c/96725758eff7b3805e4e94d1443a100757412720"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49310 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: char: xillybus: fix a refcount leak in cleanup_dev() usb_get_dev is called in xillyusb_probe. So it is better to call usb_put_dev before xdev is released. | ["https://git.kernel.org/stable/c/21f1f167d727f3f857e26d509ef5a6d47fd31bc3","https://git.kernel.org/stable/c/b67d19662fdee275c479d21853bc1239600a798f","https://git.kernel.org/stable/c/bc8fceda3b89006e8a7dda8a097d36045d044c25","https://git.kernel.org/stable/c/e277b95acdab84cd5d2f8d537a37aef6d21e988b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49329 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vduse: Fix NULL pointer dereference on sysfs access The control device has no drvdata. So we will get a NULL pointer dereference when accessing control device's msg_timeout attribute via sysfs: [ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271) [ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094) [ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59) [ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088) [ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164) [ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230) [ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041) [ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238) [ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1)) [ 132.876319][ T3644] kernel_read (fs/read_write.c:459) [ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94) [ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186) [ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207) [ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189) [ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132) [ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419) To fix it, don't create the unneeded attribute for control device anymore. | ["https://git.kernel.org/stable/c/30fd1b56621e187346f65d01fe34870634b15188","https://git.kernel.org/stable/c/3a7a81f4835dfda11f39fdd27586da14331896eb","https://git.kernel.org/stable/c/b22fdee17ec62604060fb0fda5e1414b634666e1","https://git.kernel.org/stable/c/b27ee76c74dc831d6e092eaebc2dfc9c0beed1c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49366 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix reference count leak in smb_check_perm_dacl() The issue happens in a specific path in smb_check_perm_dacl(). When "id" and "uid" have the same value, the function simply jumps out of the loop without decrementing the reference count of the object "posix_acls", which is increased by get_acl() earlier. This may result in memory leaks. Fix it by decreasing the reference count of "posix_acls" before jumping to label "check_access_bits". | ["https://git.kernel.org/stable/c/248d71b440aef829f5cc5f6545ca113ef5062900","https://git.kernel.org/stable/c/9758a6653c27867d810de02b4e5697163dda9883","https://git.kernel.org/stable/c/cf824b95c12a1abacadbc2d069931963221a3414","https://git.kernel.org/stable/c/d21a580dafc69aa04f46e6099616146a536b0724"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49392 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: 8250_aspeed_vuart: Fix potential NULL dereference in aspeed_vuart_probe platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference. | ["https://git.kernel.org/stable/c/0e0fd55719fa081de6f9e5d9e6cef48efb04d34a","https://git.kernel.org/stable/c/90a6b6fc52bfdcfe9698454bf5bea26112abbcd1","https://git.kernel.org/stable/c/923d34ce069e8e51a4d003caa6b66a8cd6ecd0ed","https://git.kernel.org/stable/c/d5f1275f101e0e8a172d300d897f5a12e87e3485"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49437 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/xive: Fix refcount leak in xive_spapr_init of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/1d1fb9618bdd5a5fbf9a9eb75133da301d33721c","https://git.kernel.org/stable/c/65f11ccdd746e0e7f0b469cc989ba43d4f30ecfe","https://git.kernel.org/stable/c/6e806485d851986a2445267608f27cb4ba2ed774","https://git.kernel.org/stable/c/cc62dde2a5f4ba14016fd9caec76f08d388f4b9c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49448 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: bcm: Check for NULL return of devm_kzalloc() As the potential failure of allocation, devm_kzalloc() may return NULL. Then the 'pd->pmb' and the follow lines of code may bring null pointer dereference. Therefore, it is better to check the return value of devm_kzalloc() to avoid this confusion. | ["https://git.kernel.org/stable/c/36339ea7bae4943be01c8e9545e46e334591fecd","https://git.kernel.org/stable/c/5650e103bfc70156001615861fb8aafb3947da6e","https://git.kernel.org/stable/c/b48b98743b568bb219152ba2e15af6ef0d3d8a9b","https://git.kernel.org/stable/c/b4bd2aafacce48db26b0a213d849818d940556dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49454 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: mediatek: Fix refcount leak in mtk_pcie_subsys_powerup() The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount. | ["https://git.kernel.org/stable/c/09b2d906d78ddf5042b1f3e0091835fc6997e8a4","https://git.kernel.org/stable/c/214e0d8fe4a813ae6ffd62bc2dfe7544c20914f4","https://git.kernel.org/stable/c/4cef4237d6c37257cb6ddc397723e9c0dded0efe","https://git.kernel.org/stable/c/ad1c9d13e04509ae24fae8dd2897148657323519"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49466 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: regulator: scmi: Fix refcount leak in scmi_regulator_probe of_find_node_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/299a002161c7bfb72e99ba45e5b660aecc344ea0","https://git.kernel.org/stable/c/4a59c763ef9b68c711dc2fd2ef4a6648da5480ee","https://git.kernel.org/stable/c/68d6c8476fd4f448e70e0ab31ff972838ac41dae","https://git.kernel.org/stable/c/9ebbfa73d69909b7c737f599fd4ebd42318fc881"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49480 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: imx-hdmi: Fix refcount leak in imx_hdmi_probe of_find_device_by_node() takes reference, we should use put_device() to release it. when devm_kzalloc() fails, it doesn't have a put_device(), it will cause refcount leak. Add missing put_device() to fix this. | ["https://git.kernel.org/stable/c/81b7edaabd44ba133006ad72056914eb36828d60","https://git.kernel.org/stable/c/8205a0114db10ec41bd2b748cdd7528632082eca","https://git.kernel.org/stable/c/cf760e494ee5fa6bc2dc222f0098c741ad460801","https://git.kernel.org/stable/c/ed46731d8e86c8d65f5fc717671e1f1f6c3146d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49485 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Fix null pointer dereference of pointer perfmon In the unlikely event that pointer perfmon is null the WARN_ON return path occurs after the pointer has already been deferenced. Fix this by only dereferencing perfmon after it has been null checked. | ["https://git.kernel.org/stable/c/1df8f8901babcc8c8eea2c067179e455b5c828fd","https://git.kernel.org/stable/c/3b72deb784a7d4ae8519a5c584cd87c4b57aa6c8","https://git.kernel.org/stable/c/4be045434923e549a50846a066a04b7b6c1d6d33","https://git.kernel.org/stable/c/ce7a1ecf3f9f1fccaf67295307614511d8e11b13"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49487 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: intel: fix possible null-ptr-deref in ebu_nand_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. | ["https://git.kernel.org/stable/c/daa5166450b447415aeeaac0199e445bae7bd0f2","https://git.kernel.org/stable/c/ddf66aefd685fd46500b9917333e1b1e118276dc","https://git.kernel.org/stable/c/e5b1e419cdb6dd8709eb05ed34039a3ded8e6003","https://git.kernel.org/stable/c/f8e262eb7575a4a2412f30f7a1b293875aceba80"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49507 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: regulator: da9121: Fix uninit-value in da9121_assign_chip_model() KASAN report slab-out-of-bounds in __regmap_init as follows: BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841 Read of size 1 at addr ffff88803678cdf1 by task xrun/9137 CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88 print_report.cold+0xcd/0x69b mm/kasan/report.c:313 kasan_report+0x8e/0xc0 mm/kasan/report.c:491 __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841 __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266 __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394 da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039 i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563 This happend when da9121 device is probe by da9121_i2c_id, but with invalid dts. Thus, chip->subvariant_id is set to -EINVAL, and later da9121_assign_chip_model() will access 'regmap' without init it. Fix it by return -EINVAL from da9121_assign_chip_model() if 'chip->subvariant_id' is invalid. | ["https://git.kernel.org/stable/c/60f21eda69f1b5727a97d2077da766eb27fcc21f","https://git.kernel.org/stable/c/7da64c7c82c9b29b628a62c88a8c2fb06990563d","https://git.kernel.org/stable/c/bab76514aca36bc513224525d5598da676938218","https://git.kernel.org/stable/c/be96baa0c79588084e0d7a4fa21c574cec9a57f4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49618 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux() pdesc could be null but still dereference pdesc->name and it will lead to a null pointer access. So we move a null check before dereference. | ["https://git.kernel.org/stable/c/3cb392b64304a05bf647e2e44efacd9a1f3c3c6a","https://git.kernel.org/stable/c/84a85d3fef2e75b1fe9fc2af6f5267122555a1ed","https://git.kernel.org/stable/c/e162a24f1dd06c0dcae71f2565c9f3da2827b98e","https://git.kernel.org/stable/c/ef1e38532f4b2f0f3b460e938a2e7076c3bed5ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49627 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ima: Fix potential memory leak in ima_init_crypto() On failure to allocate the SHA1 tfm, IMA fails to initialize and exits without freeing the ima_algo_array. Add the missing kfree() for ima_algo_array to avoid the potential memory leak. | ["https://git.kernel.org/stable/c/067d2521874135267e681c19d42761c601d503d6","https://git.kernel.org/stable/c/601ae26aa2802a4c10c94d7388a99eabdbefab2b","https://git.kernel.org/stable/c/830de9667b3ada0a75a3f098dfc7159709fe397b","https://git.kernel.org/stable/c/c1d9702ceb4a091da6bee380627596d1fba09274"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49664 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: move bc link creation back to tipc_node_create Shuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] <IRQ> [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc] It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When it creates a node in tipc_node_check_dest(), after inserting the new node into hashtable in tipc_node_create(), it creates the bc link. However, there is a gap between this insert and bc link creation, a bc packet may come in and get the node from the hashtable then try to dereference its bc link, which is NULL. This patch is to fix it by moving the bc link creation before inserting into the hashtable. Note that for a preliminary node becoming "real", the bc link creation should also be called before it's rehashed, as we don't create it for preliminary nodes. | ["https://git.kernel.org/stable/c/35fcb2ba35b4d9b592b558c3bcc6e0d90e213588","https://git.kernel.org/stable/c/456bc338871c4a52117dd5ef29cce3745456d248","https://git.kernel.org/stable/c/cb8092d70a6f5f01ec1490fce4d35efed3ed996c","https://git.kernel.org/stable/c/e52910e671f58c619e33dac476b11b35e2d3ab6f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49671 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/cm: Fix memory leak in ib_cm_insert_listen cm_alloc_id_priv() allocates resource for the cm_id_priv. When cm_init_listen() fails it doesn't free it, leading to memory leak. Add the missing error unwind. | ["https://git.kernel.org/stable/c/2990f223ffa7bb25422956b9f79f9176a5b38346","https://git.kernel.org/stable/c/2febf09a8a8ae4accf908f043f1bab1421056568","https://git.kernel.org/stable/c/889000874c1204e47c7f2a4945db262a47e7efc9","https://git.kernel.org/stable/c/b0cab8b517aeaf2592c3479294f934209c41a26f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49676 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. This function doesn't call of_node_put() in some error paths. To unify the structure, Add put_node label and goto it on errors. | ["https://git.kernel.org/stable/c/1332661e09304b7b8e84e5edc11811ba08d12abe","https://git.kernel.org/stable/c/889aad2203e09eed2071ca8985c25e9d6aea5735","https://git.kernel.org/stable/c/bb2a481778c60f912c363e271ae46b55ff8132db","https://git.kernel.org/stable/c/cde4480b5ab06195b9164184b0c02ced71e601b4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49683 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/501652a2ad5450b4908e1f204ce75b2414c305b7","https://git.kernel.org/stable/c/5eaa84e1605035a90a64d25b6cba79e89d188175","https://git.kernel.org/stable/c/ab7bf025cee89db73c649216ddd2bc589c3d3862","https://git.kernel.org/stable/c/ada7b0c0dedafd7d059115adf49e48acba3153a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49728 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix signed integer overflow in __ip6_append_data Resurrect ubsan overflow checks and ubsan report this warning, fix it by change the variable [length] type to size_t. UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:19 2147479552 + 8567 cannot be represented in type 'int' CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170 Changes since v1: -Change the variable [length] type to unsigned, as Eric Dumazet suggested. Changes since v2: -Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested. Changes since v3: -Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, as Jakub Kicinski suggested. | ["https://git.kernel.org/stable/c/70549c80fe80ac4e2a22068c76ebebced24f7e74","https://git.kernel.org/stable/c/84dc940890e91e42898e4443a093281702440abf","https://git.kernel.org/stable/c/f26422eabeb517629568edf8c2dd9c6cb9147584","https://git.kernel.org/stable/c/f93431c86b631bbca5614c66f966bf3ddb3c2803"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2016-3695 | Medium | N/A | The einj_error_inject function in drivers/acpi/apei/einj.c in the Linux kernel allows local users to simulate hardware errors and consequently cause a denial of service by leveraging failure to disable APEI error injection through EINJ when securelevel is set. | ["http://www.securityfocus.com/bid/102327","https://bugzilla.redhat.com/show_bug.cgi?id=1322755","https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420","http://www.securityfocus.com/bid/102327","https://bugzilla.redhat.com/show_bug.cgi?id=1322755","https://github.com/mjg59/linux/commit/d7a6be58edc01b1c66ecd8fcc91236bfbce0a420"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49738 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to do sanity check on i_extra_isize in is_alive() syzbot found a f2fs bug: BUG: KASAN: slab-out-of-bounds in data_blkaddr fs/f2fs/f2fs.h:2891 [inline] BUG: KASAN: slab-out-of-bounds in is_alive fs/f2fs/gc.c:1117 [inline] BUG: KASAN: slab-out-of-bounds in gc_data_segment fs/f2fs/gc.c:1520 [inline] BUG: KASAN: slab-out-of-bounds in do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 Read of size 4 at addr ffff888076557568 by task kworker/u4:3/52 CPU: 1 PID: 52 Comm: kworker/u4:3 Not tainted 6.1.0-rc4-syzkaller-00362-gfef7fd48922d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Workqueue: writeback wb_workfn (flush-7:0) Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x15e/0x45d mm/kasan/report.c:395 kasan_report+0xbb/0x1f0 mm/kasan/report.c:495 data_blkaddr fs/f2fs/f2fs.h:2891 [inline] is_alive fs/f2fs/gc.c:1117 [inline] gc_data_segment fs/f2fs/gc.c:1520 [inline] do_garbage_collect+0x386a/0x3df0 fs/f2fs/gc.c:1734 f2fs_gc+0x88c/0x20a0 fs/f2fs/gc.c:1831 f2fs_balance_fs+0x544/0x6b0 fs/f2fs/segment.c:410 f2fs_write_inode+0x57e/0xe20 fs/f2fs/inode.c:753 write_inode fs/fs-writeback.c:1440 [inline] __writeback_single_inode+0xcfc/0x1440 fs/fs-writeback.c:1652 writeback_sb_inodes+0x54d/0xf90 fs/fs-writeback.c:1870 wb_writeback+0x2c5/0xd70 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x2dc/0x12f0 fs/fs-writeback.c:2227 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 The root cause is that we forgot to do sanity check on .i_extra_isize in below path, result in accessing invalid address later, fix it. - gc_data_segment - is_alive - data_blkaddr - offset_in_addr | ["https://git.kernel.org/stable/c/5b25035fb888cb2f78bf0b9c9f95b1dc54480d36","https://git.kernel.org/stable/c/914e38f02a490dafd980ff0f39cccedc074deb29","https://git.kernel.org/stable/c/97ccfffcc061e54ce87e4a51a40e2e9cb0b7076a","https://git.kernel.org/stable/c/d3b7b4afd6b2c344eabf9cc26b8bfa903c164c7c","https://git.kernel.org/stable/c/e5142a4935c1f15841d06047b8130078fc4d7b8f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1989 | High | fixed |
|
A use-after-free flaw was found in btsdio_remove in drivers\bluetooth\btsdio.c in the Linux Kernel. In this flaw, a call to btsdio_remove with an unfinished job, may cause a race problem leading to a UAF on hdev devices. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230601-0004/","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=f132c2d13088","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230601-0004/","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56572 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal() The buffer in the loop should be released under the exception path, otherwise there may be a memory leak here. To mitigate this, free the buffer when allegro_alloc_buffer fails. | ["https://git.kernel.org/stable/c/0f514068fbc5d4d189c817adc7c4e32cffdc2e47","https://git.kernel.org/stable/c/17e5613666209be4e5be1f1894f1a6014a8a0658","https://git.kernel.org/stable/c/64f72a738864b506ab50b4a6cb3ce3c3e04b71af","https://git.kernel.org/stable/c/6712a28a4f923ffdf51cff267ad05a634ee1babc","https://git.kernel.org/stable/c/74a65313578b35e1239966adfa7ac2bdd60caf00","https://git.kernel.org/stable/c/891b5790bee8fc6ddba17874dd87a646128d0b99","https://git.kernel.org/stable/c/cf642904be39ae0d441dbdfa8f485e0a46260be4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56643 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dccp: Fix memory leak in dccp_feat_change_recv If dccp_feat_push_confirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccp_feat_clone_sp_val() is never freed. Here is the kmemleak stack for this: unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Clean up the allocated memory in case of dccp_feat_push_confirm() failure and bail out with an error reset code. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/22be4727a8f898442066bcac34f8a1ad0bc72e14","https://git.kernel.org/stable/c/623be080ab3c13d71570bd32f7202a8efa8e2252","https://git.kernel.org/stable/c/6ff67909ee2ffad911e3122616df41dee23ff4f6","https://git.kernel.org/stable/c/9ee68b0f23706a77f53c832457b9384178b76421","https://git.kernel.org/stable/c/bc3d4423def1a9412a0ae454cb4477089ab79276","https://git.kernel.org/stable/c/c99507fff94b926fc92279c92d80f229c91cb85d","https://git.kernel.org/stable/c/d3ec686a369fae5034303061f003cd3f94ddfd23"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-20265 | Medium | N/A | A flaw was found in the way memory resources were freed in the unix_stream_recvmsg function in the Linux kernel when a signal was pending. This flaw allows an unprivileged local user to crash the system by exhausting available memory. The highest threat from this vulnerability is to system availability. | ["https://bugzilla.redhat.com/show_bug.cgi?id=1908827","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa0dc04df259ba2df3ce1920e9690c7842f8fa4b","https://www.oracle.com/security-alerts/cpuoct2021.html","https://bugzilla.redhat.com/show_bug.cgi?id=1908827","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa0dc04df259ba2df3ce1920e9690c7842f8fa4b","https://www.oracle.com/security-alerts/cpuoct2021.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0617 | Medium | fixed |
|
A flaw null pointer dereference in the Linux kernel UDF file system functionality was found in the way user triggers udf_file_write_iter function for the malicious UDF image. A local user could use this flaw to crash the system. Actual from Linux kernel 4.2-rc1 till 5.17-rc2. | ["http://www.openwall.com/lists/oss-security/2022/04/13/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/","https://www.debian.org/security/2022/dsa-5095","https://www.debian.org/security/2022/dsa-5096","http://www.openwall.com/lists/oss-security/2022/04/13/2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7fc3b7c2981bbd1047916ade327beccb90994eee","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea8569194b43f0f01f0a84c689388542c7254a1f","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/lkml/20220114172329.ygzry5rlz64ua2nr%40quack3.lan/T/","https://www.debian.org/security/2022/dsa-5095","https://www.debian.org/security/2022/dsa-5096"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26793 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [ 1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [ 1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ? asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ? unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ? arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ? stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ? mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ? __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ? lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196] netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ? netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ? netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233] netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ? __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ? netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ? netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290] ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ? drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated--- | ["https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb","https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8","https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e","https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16","https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e","https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627","https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69","https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6","https://git.kernel.org/stable/c/01129059d5141d62fae692f7a336ae3bc712d3eb","https://git.kernel.org/stable/c/5366969a19a8a0d2ffb3d27ef6e8905e5e4216f8","https://git.kernel.org/stable/c/616d82c3cfa2a2146dd7e3ae47bda7e877ee549e","https://git.kernel.org/stable/c/9376d059a705c5dfaac566c2d09891242013ae16","https://git.kernel.org/stable/c/93dd420bc41531c9a31498b9538ca83ba6ec191e","https://git.kernel.org/stable/c/abd32d7f5c0294c1b2454c5a3b13b18446bac627","https://git.kernel.org/stable/c/e668b92a3a01429923fd5ca13e99642aab47de69","https://git.kernel.org/stable/c/ec92aa2cab6f0048f10d6aa4f025c5885cb1a1b6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49059 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: add flush_workqueue to prevent uaf Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue). The race can be demonstrated below: Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF. This UAF is easy to trigger, crash trace by POC is like below [ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0x ---truncated--- | ["https://git.kernel.org/stable/c/1a1748d0dd0f0a98535c6baeef671c8722107639","https://git.kernel.org/stable/c/5c63ad2b0a267a524c12c88acb1ba9c2d109a801","https://git.kernel.org/stable/c/67677050cecbe0edfdd81cd508415e9636ba7c65","https://git.kernel.org/stable/c/7d3232214ca4ea8f7d18df264c3b254aa8089d7f","https://git.kernel.org/stable/c/9d243aff5f7e6b04e907c617426bbdf26e996ac8","https://git.kernel.org/stable/c/9ded5ae40f4fe37fcc28f36d76bf45df20be5432","https://git.kernel.org/stable/c/edd4600120641e1714e30112e69a548cfb68e067","https://git.kernel.org/stable/c/ef27324e2cb7bb24542d6cb2571740eefe6b00dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4921 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation. When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue(). We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8","https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8fc134fee27f2263988ae38920bc03da416b03d8","https://kernel.dance/8fc134fee27f2263988ae38920bc03da416b03d8","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3176 | High | fixed |
|
There exists a use-after-free in io_uring in the Linux kernel. Signalfd_poll() and binder_poll() use a waitqueue whose lifetime is the current task. It will send a POLLFREE notification to all waiters before the queue is freed. Unfortunately, the io_uring poll doesn't handle POLLFREE. This allows a use-after-free to occur if a signalfd or binder fd is polled with io_uring poll, and the waitqueue gets freed. We recommend upgrading past commit fc78b2fc21f10c4c9c4d5d659a685710ffa63659 | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y\u0026id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://security.netapp.com/advisory/ntap-20230216-0003/","https://www.debian.org/security/2022/dsa-5257","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-5.4.y\u0026id=fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://kernel.dance/#fc78b2fc21f10c4c9c4d5d659a685710ffa63659","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://security.netapp.com/advisory/ntap-20230216-0003/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52531 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()'ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) 'mvm->nvm_data' is a 'struct iwl_nvm_data', so it is fine. At the end of this structure, there is the 'channels' flex array. Each element is of type 'struct ieee80211_channel'. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the 'channels' flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the "(u8 *)" cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the 'struct ieee80211_rate' allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected. | ["https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0","https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef","https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d","https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128","https://git.kernel.org/stable/c/6b3223449c959a8be94a1f042288059e40fcccb0","https://git.kernel.org/stable/c/7c8faa31080342aec4903c9acb20caf82fcca1ef","https://git.kernel.org/stable/c/8ba438ef3cacc4808a63ed0ce24d4f0942cfe55d","https://git.kernel.org/stable/c/f06cdd8d4ba5252986f51f80cc30263636397128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1158 | High | fixed |
|
A flaw was found in KVM. When updating a guest's page table entry, vm_pgoff was improperly used as the offset to get the page's pfn. As vaddr and vm_pgoff are controllable by user-mode processes, this flaw allows unprivileged local users on the host to write outside the userspace region and potentially corrupt the kernel, resulting in a denial of service condition. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2069793","https://security.netapp.com/advisory/ntap-20230214-0003/","https://www.openwall.com/lists/oss-security/2022/04/08/4","https://bugzilla.redhat.com/show_bug.cgi?id=2069793","https://security.netapp.com/advisory/ntap-20230214-0003/","https://www.openwall.com/lists/oss-security/2022/04/08/4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3609 | High | fixed |
|
A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation. If tcf_change_indev() fails, u32_set_parms() will immediately return an error after incrementing or decrementing the reference counter in tcf_bind_filter(). If an attacker can control the reference counter and set it to zero, they can cause the reference to be freed, leading to a use-after-free vulnerability. We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc. | ["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc","https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=04c55383fa5689357bcdd2c8036725a55ed632bc","https://kernel.dance/04c55383fa5689357bcdd2c8036725a55ed632bc","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230818-0005/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1118 | High | fixed |
|
A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. | ["https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230413-0003/","https://github.com/torvalds/linux/commit/29b0589a865b6f66d141d79b2dd1373e4e50fe17","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230413-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-51042 | High | fixed |
|
In the Linux kernel before 6.4.12, amdgpu_cs_wait_all_fences in drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c has a fence use-after-free. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://github.com/torvalds/linux/commit/2e54154b9f27262efd0cb4f903cc7d5ad1fe9628","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.12","https://github.com/torvalds/linux/commit/2e54154b9f27262efd0cb4f903cc7d5ad1fe9628"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2978 | High | fixed |
|
A flaw use after free in the Linux kernel NILFS file system was found in the way user triggers function security_inode_alloc to fail with following call to function nilfs_mdt_destroy. A local user could use this flaw to crash the system or potentially escalate their privileges on the system. | ["https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lore.kernel.org/linux-fsdevel/20220816040859.659129-1-dzm91%40hust.edu.cn/T/#u"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-39189 | High | fixed |
|
An issue was discovered the x86 KVM subsystem in the Linux kernel before 5.18.17. Unprivileged guest users can compromise the guest kernel because TLB flush operations are mishandled in certain KVM_VCPU_PREEMPTED situations. | ["https://bugs.chromium.org/p/project-zero/issues/detail?id=2309","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736","https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230214-0007/","https://www.debian.org/security/2023/dsa-5480","https://bugs.chromium.org/p/project-zero/issues/detail?id=2309","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.17","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd88243c7e03845a450795e134b488fc2afb736","https://github.com/torvalds/linux/commit/6cd88243c7e03845a450795e134b488fc2afb736","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230214-0007/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3111 | High | fixed |
|
A use after free vulnerability was found in prepare_to_relocate in fs/btrfs/relocation.c in btrfs in the Linux Kernel. This possible flaw can be triggered by calling btrfs_ioctl_balance() before calling btrfs_ioctl_defrag(). | ["https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/","https://security.netapp.com/advisory/ntap-20230703-0007/","https://www.debian.org/security/2023/dsa-5480","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://patchwork.kernel.org/project/linux-btrfs/patch/20220721074829.2905233-1-r33s3n6%40gmail.com/","https://security.netapp.com/advisory/ntap-20230703-0007/","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49755 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait While performing fast composition switch, there is a possibility that the process of ffs_ep0_write/ffs_ep0_read get into a race condition due to ep0req being freed up from functionfs_unbind. Consider the scenario that the ffs_ep0_write calls the ffs_ep0_queue_wait by taking a lock &ffs->ev.waitq.lock. However, the functionfs_unbind isn't bounded so it can go ahead and mark the ep0req to NULL, and since there is no NULL check in ffs_ep0_queue_wait we will end up in use-after-free. Fix this by making a serialized execution between the two functions using a mutex_lock(ffs->mutex). | ["https://git.kernel.org/stable/c/6a19da111057f69214b97c62fb0ac59023970850","https://git.kernel.org/stable/c/6aee197b7fbcd61596a78b47d553f2f99111f217","https://git.kernel.org/stable/c/6dd9ea05534f323668db94fcc2726c7a84547e78","https://git.kernel.org/stable/c/a8d40942df074f4ebcb9bd3413596d92f323b064","https://git.kernel.org/stable/c/ae8e136bcaae96163b5821984de1036efc9abb1a","https://git.kernel.org/stable/c/e9036e951f93fb8d7b5e9d6e2c7f94a4da312ae4","https://git.kernel.org/stable/c/facf353c9e8d7885b686d9a4b173d4e0af6441d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1281 | High | fixed |
|
Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when 'tcf_exts_exec()' is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root. This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2. | ["http://www.openwall.com/lists/oss-security/2023/04/11/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230427-0004/","http://www.openwall.com/lists/oss-security/2023/04/11/3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://kernel.dance/#ee059170b1f7e94e55fa6cadee544e176a6e59c2","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230427-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52988 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: hda/via: Avoid potential array out-of-bound in add_secret_dac_path() snd_hda_get_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/1b9256c96220bcdba287eeeb90e7c910c77f8c46","https://git.kernel.org/stable/c/2b557fa635e7487f638c0f030c305870839eeda2","https://git.kernel.org/stable/c/437e50ef6290ac835d526d0e45f466a0aa69ba1b","https://git.kernel.org/stable/c/6e1f586ddec48d71016b81acf68ba9f49ca54db8","https://git.kernel.org/stable/c/b9cee506da2b7920b5ea02ccd8e78a907d0ee7aa","https://git.kernel.org/stable/c/d6870f3800dbb212ae8433183ee82f566d067c6c","https://git.kernel.org/stable/c/f011360ad234a07cb6fbcc720fff646a93a9f0d6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22040 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix session use-after-free in multichannel connection There is a race condition between session setup and ksmbd_sessions_deregister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it. | ["https://git.kernel.org/stable/c/3980770cb1470054e6400fd97668665975726737","https://git.kernel.org/stable/c/596407adb9af1ee75fe7c7529607783d31b66e7f","https://git.kernel.org/stable/c/7dfbd4c43eed91dd2548a95236908025707a8dfd","https://git.kernel.org/stable/c/9069939d762138e232a6f79e3e1462682ed6a17d","https://git.kernel.org/stable/c/94c281721d4ed2d972232414b91d98a6f5bdb16b","https://git.kernel.org/stable/c/fa4cdb8cbca7d6cb6aa13e4d8d83d1103f6345db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22041 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in ksmbd_sessions_deregister() In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection. | ["https://git.kernel.org/stable/c/15a9605f8d69dc85005b1a00c31a050b8625e1aa","https://git.kernel.org/stable/c/33cc29e221df7a3085ae413e8c26c4e81a151153","https://git.kernel.org/stable/c/8ed0e9d2f410f63525afb8351181eea36c80bcf1","https://git.kernel.org/stable/c/a8a8ae303a8395cbac270b5b404d85df6ec788f8","https://git.kernel.org/stable/c/ca042cc0e4f9e0d2c8f86dd67e4b22f30a516a9b","https://git.kernel.org/stable/c/f0eb3f575138b816da74697bd506682574742fcd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22097 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vkms: Fix use after free and double free on init error If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. | ["https://git.kernel.org/stable/c/1f68f1cf09d06061eb549726ff8339e064eddebd","https://git.kernel.org/stable/c/49a69f67f53518bdd9b7eeebf019a2da6cc0e954","https://git.kernel.org/stable/c/561fc0c5cf41f646f3e9e61784cbc0fc832fb936","https://git.kernel.org/stable/c/79d138d137b80eeb0a83244d1cff29e64cf91067","https://git.kernel.org/stable/c/b8a18bb53e06d6d3c1fd03d12533d6e333ba8853","https://git.kernel.org/stable/c/d5eb8e347905ab17788a7903fa1d3d06747355f5","https://git.kernel.org/stable/c/ed15511a773df86205bda66c37193569575ae828"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49761 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: always report error in run_one_delayed_ref() Currently we have a btrfs_debug() for run_one_delayed_ref() failure, but if end users hit such problem, there will be no chance that btrfs_debug() is enabled. This can lead to very little useful info for debugging. This patch will: - Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod - Replace the btrfs_debug() with btrfs_err() - Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller. This error should only be triggered at most once. As if run_one_delayed_ref() failed, we trigger the error message, then causing the call chain to error out: btrfs_run_delayed_refs() `- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref() And we will abort the current transaction in btrfs_run_delayed_refs(). If we have to run delayed refs for the abort transaction, run_one_delayed_ref() will just cleanup the refs and do nothing, thus no new error messages would be output. | ["https://git.kernel.org/stable/c/18bd1c9c02e64a3567f90c83c2c8b855531c8098","https://git.kernel.org/stable/c/39f501d68ec1ed5cd5c66ac6ec2a7131c517bb92","https://git.kernel.org/stable/c/853ffa1511b058c79a4c9bb1407b3b20ce311792","https://git.kernel.org/stable/c/fdb4a70bb768d2a87890409597529ad81cb3de8a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3566 | High | N/A | A vulnerability, which was classified as problematic, was found in Linux Kernel. This affects the function tcp_getsockopt/tcp_setsockopt of the component TCP Handler. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. The identifier VDB-211089 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57","https://vuldb.com/?id.211089","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57","https://vuldb.com/?id.211089"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50006 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add | ["https://git.kernel.org/stable/c/3c46d6060d3e38de22196c1fe7706c5a3c696285","https://git.kernel.org/stable/c/4192adefc9c570698821c5eb9873320eac2fcbf1","https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44","https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820","https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870","https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f","https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194","https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729","https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22027 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: streamzap: fix race between device disconnection and urb callback Syzkaller has reported a general protection fault at function ir_raw_event_store_with_filter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzap_disconnect() function: rc_unregister_device() is called before usb_kill_urb(). The dev->raw pointer is freed and set to NULL in rc_unregister_device(), and only after that usb_kill_urb() waits for in-progress requests to finish. If rc_unregister_device() is called while streamzap_callback() handler is not finished, this can lead to accessing freed resources. Thus rc_unregister_device() should be called after usb_kill_urb(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/15483afb930fc2f883702dc96f80efbe4055235e","https://git.kernel.org/stable/c/30ef7cfee752ca318d5902cb67b60d9797ccd378","https://git.kernel.org/stable/c/4db62b60af2ccdea6ac5452fd20e29587ed85f57","https://git.kernel.org/stable/c/8760da4b9d44c36b93b6e4cf401ec7fe520015bd","https://git.kernel.org/stable/c/adf0ddb914c9e5b3e50da4c97959e82de2df75c3","https://git.kernel.org/stable/c/e11652a6514ec805440c1bb3739e6c6236fffcc7","https://git.kernel.org/stable/c/f1d518c0bad01abe83c2df880274cb6a39f4a457","https://git.kernel.org/stable/c/f656cfbc7a293a039d6a0c7100e1c846845148c1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-24959 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 5.16.5. There is a memory leak in yam_siocdevprivate in drivers/net/hamradio/yam.c. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://github.com/torvalds/linux/commit/29eb31542787e1019208a2e1047bb7c76c069536","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://github.com/torvalds/linux/commit/29eb31542787e1019208a2e1047bb7c76c069536","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1184 | Medium | fixed |
|
A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the Linux kernel’s filesystem sub-component. This flaw allows a local attacker with a user privilege to cause a denial of service. | ["https://access.redhat.com/security/cve/CVE-2022-1184","https://bugzilla.redhat.com/show_bug.cgi?id=2070205","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://ubuntu.com/security/CVE-2022-1184","https://www.debian.org/security/2022/dsa-5257","https://access.redhat.com/security/cve/CVE-2022-1184","https://bugzilla.redhat.com/show_bug.cgi?id=2070205","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://ubuntu.com/security/CVE-2022-1184","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46827 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix firmware crash due to invalid peer nss Currently, if the access point receives an association request containing an Extended HE Capabilities Information Element with an invalid MCS-NSS, it triggers a firmware crash. This issue arises when EHT-PHY capabilities shows support for a bandwidth and MCS-NSS set for that particular bandwidth is filled by zeros and due to this, driver obtains peer_nss as 0 and sending this value to firmware causes crash. Address this issue by implementing a validation step for the peer_nss value before passing it to the firmware. If the value is greater than zero, proceed with forwarding it to the firmware. However, if the value is invalid, reject the association request to prevent potential firmware crashes. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/25a15f80253a7c8776e4e4880d797d20ec864154","https://git.kernel.org/stable/c/838c2cfdb6be7d7d8c06c711edf893eb34ca2e7c","https://git.kernel.org/stable/c/db163a463bb93cd3e37e1e7b10b9726fb6f95857"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47641 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: cirrusfb: check pixclock to avoid divide by zero Do a sanity check on pixclock value to avoid divide by zero. If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible. Syzkaller reported a divide error in cirrusfb_check_pixclock. divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfb_test Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfb_check_var+0x6f1/0x1260 Call Trace: fb_set_var+0x398/0xf90 do_fb_ioctl+0x4b8/0x6f0 fb_ioctl+0xeb/0x130 __x64_sys_ioctl+0x19d/0x220 do_syscall_64+0x3a/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/1d3fb46439ad4e8f0c5739eb33d1875ac9e0f135","https://git.kernel.org/stable/c/40b13e3d85744210db13457785646634e2d056bd","https://git.kernel.org/stable/c/45800c42ef000f417270bcfc08630e42486fca99","https://git.kernel.org/stable/c/53a2088a396cfa1da92690a1da289634cd73bf0d","https://git.kernel.org/stable/c/5c6f402bdcf9e7239c6bc7087eda71ac99b31379","https://git.kernel.org/stable/c/6fe23ff94e7840097202e85c148688940b37c9b1","https://git.kernel.org/stable/c/8c7e2141fb89c620ab4e41512e262fbf25b8260d","https://git.kernel.org/stable/c/c656d04247a2654ede5cead2ecbf83431dad5261","https://git.kernel.org/stable/c/e498b504f8c81b07efab9febf8503448de4dc9cf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47652 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe() I got a null-ptr-deref report: BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:fb_destroy_modelist+0x38/0x100 ... Call Trace: ufx_usb_probe.cold+0x2b5/0xac1 [smscufx] usb_probe_interface+0x1aa/0x3c0 [usbcore] really_probe+0x167/0x460 ... ret_from_fork+0x1f/0x30 If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will be called to destroy modelist in the error handling path. But modelist has not been initialized yet, so it will result in null-ptr-deref. Initialize modelist before calling fb_alloc_cmap() to fix this bug. | ["https://git.kernel.org/stable/c/0fd28daec73525382e5c992db8743bf76e42cd5c","https://git.kernel.org/stable/c/1791f487f877a9e83d81c8677bd3e7b259e7cb27","https://git.kernel.org/stable/c/64ec3e678d76419f207b9cdd338dda438ca10b1c","https://git.kernel.org/stable/c/9280ef235b05e8f19f8bc6d547b992f0a0ef398d","https://git.kernel.org/stable/c/c420b540db4b5d69de0a36d8b9d9a6a79a04f05a","https://git.kernel.org/stable/c/d1b6a1f0c23b7164250479bf92e2893291dca539","https://git.kernel.org/stable/c/d396c651e2b508b6179bb678cc029f3becbf5170","https://git.kernel.org/stable/c/da8b269cc0a2526ebeaccbe2484c999eb0f822cf","https://git.kernel.org/stable/c/dd3a6cc7385b89ec2303f39dfc3bafa4e24cec4b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49185 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pinctrl: nomadik: Add missing of_node_put() in nmk_pinctrl_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. | ["https://git.kernel.org/stable/c/0067ba448f1c29ca06e5aee00d8506889ed1f9d0","https://git.kernel.org/stable/c/0356d4b64a03d23daf99a2a29d7d7d91d6ec2ea8","https://git.kernel.org/stable/c/59250d547542f1c7765a78dc97ddfe5e6b0d2ab0","https://git.kernel.org/stable/c/62580a40c9bef3d8a90629c64dda381344b35ffd","https://git.kernel.org/stable/c/669b05ff43bd7ed684379c6e2006a6dad5127b71","https://git.kernel.org/stable/c/9511c6018cd772668def8b034bc67269847e591a","https://git.kernel.org/stable/c/bc1e29a35147c1ba6ea2b06a16cb0028f7c852d2","https://git.kernel.org/stable/c/c09ac191b1f97cfa06f394dbfd7a5db07986cefc","https://git.kernel.org/stable/c/c52703355766c347f270df222a744e0c491a02f2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49216 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix reference leak in tegra_dsi_ganged_probe The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add put_device() call to fix this. | ["https://git.kernel.org/stable/c/0e2f4e434e71dffd1085c3dccd676514bd71d316","https://git.kernel.org/stable/c/1e06710c43a090f14bb67714265a01cd1d7a37c5","https://git.kernel.org/stable/c/221e3638feb8bc42143833c9a704fa89b6c366bb","https://git.kernel.org/stable/c/2d6ae8b747fe55f54de4a4441d636974aa53f56a","https://git.kernel.org/stable/c/5e8fdb6392d945d33fef959eab73f8c34bc0a63b","https://git.kernel.org/stable/c/852c1f5f3119a38ee68e319bab10277fc1ab06b7","https://git.kernel.org/stable/c/a725070701883fe62266ee6d2f31d67e6cdd31df","https://git.kernel.org/stable/c/cd78b74031cbc94133965f1017deb822657fc1a6","https://git.kernel.org/stable/c/f3c99c686e098300c246e5e8a1474133e3dacb05"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49224 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()： If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix memory leak by calling kobject_put(). | ["https://git.kernel.org/stable/c/19aa3c98ed7b2616e105946cec804f897837ab84","https://git.kernel.org/stable/c/261041097ab3470f1120b7733cbf472712304d1e","https://git.kernel.org/stable/c/31cdf7897dba1f096b74f69d840f0575b8cdb9ae","https://git.kernel.org/stable/c/41ed61364285ff38bbbe9ca8a45c8372ba72921d","https://git.kernel.org/stable/c/6a4760463dbc6b603690938c468839985189ce0a","https://git.kernel.org/stable/c/879356a6a05559582b0a7895d86d2d4359745c08","https://git.kernel.org/stable/c/c32f6b6196b6efc1c68990dfeaac36fb8eb3b8e1","https://git.kernel.org/stable/c/db3a61ef8e6aef3b888baa6a85926c2230c2cc56","https://git.kernel.org/stable/c/ffb8e92b4cef92bd25563cf3d8b4489eb22bc61f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49235 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath9k_htc: fix uninit value bugs Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing field initialization. In htc_connect_service() svc_meta_len and pad are not initialized. Based on code it looks like in current skb there is no service data, so simply initialize svc_meta_len to 0. htc_issue_send() does not initialize htc_frame_hdr::control array. Based on firmware code, it will initialize it by itself, so simply zero whole array to make KMSAN happy Fail logs: BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 4-7 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430 hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline] hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479 htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline] htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275 ... Uninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258 ... Bytes 16-17 of 18 are uninitialized Memory access of size 18 starts at ffff888027377e00 | ["https://git.kernel.org/stable/c/0b700f7d06492de34964b6f414120043364f8191","https://git.kernel.org/stable/c/11f11ac281f0c0b363d2940204f28bae0422ed71","https://git.kernel.org/stable/c/4d244b731188e0b63fc40a9d2dec72e9181fb37c","https://git.kernel.org/stable/c/5abf2b761b998063f5e2bae93fd4ab10e2a80f10","https://git.kernel.org/stable/c/5c2a6a8daa17a3f65b38b9a5574bb362c13fa1d9","https://git.kernel.org/stable/c/7da6169b6ebb75816b57be3beb829afa74f3b4b6","https://git.kernel.org/stable/c/d1e0df1c57bd30871dd1c855742a7c346dbca853","https://git.kernel.org/stable/c/e352acdd378e9263cc4c6018e588f2dac7161d07","https://git.kernel.org/stable/c/ee4222052a76559c20e821bc3519cefb58b6d3e9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49242 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs: Fix error handling in mxs_sgtl5000_probe This function only calls of_node_put() in the regular path. And it will cause refcount leak in error paths. For example, when codec_np is NULL, saif_np[0] and saif_np[1] are not NULL, it will cause leaks. of_node_put() will check if the node pointer is NULL, so we can call it directly to release the refcount of regular pointers. | ["https://git.kernel.org/stable/c/44acdaf7acb60054d872bed18ce0e7db8ce900ce","https://git.kernel.org/stable/c/67e12f1cb2f97468c12b59e21975eaa0f332e7d2","https://git.kernel.org/stable/c/6ae0a4d8fec551ec581d620f0eb1fe31f755551c","https://git.kernel.org/stable/c/790d2628e3fcc819d8f5572eb5615113fb2e727a","https://git.kernel.org/stable/c/86b6cf989437e694fd0a15782b5a513853a739e0","https://git.kernel.org/stable/c/8d880226c86f37624e2a5f3c6d92ac0ec3375f96","https://git.kernel.org/stable/c/d2923b48d99fe663cb93d8b481c93299fcd68656","https://git.kernel.org/stable/c/f16ad2c0e22687f80e5981c67374023f51c204b9","https://git.kernel.org/stable/c/f8d38056bcd220ea6f0802a5586d1a12ebcce849"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49276 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_scan_medium If an error is returned in jffs2_scan_eraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [<ffffffffae93a3a3>] __kmalloc+0x613/0x910 [<ffffffffaf423b9c>] jffs2_sum_add_dirent_mem+0x5c/0xa0 [<ffffffffb0f3afa8>] jffs2_scan_medium.cold+0x36e5/0x4794 [<ffffffffb0f3dbe1>] jffs2_do_mount_fs.cold+0xa7/0x2267 [<ffffffffaf40acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffaf40c00a>] jffs2_fill_super+0x2ea/0x4c0 [<ffffffffb0315d64>] mtd_get_sb+0x254/0x400 [<ffffffffb0315f5f>] mtd_get_sb_by_nr+0x4f/0xd0 [<ffffffffb0316478>] get_tree_mtd+0x498/0x840 [<ffffffffaf40bd15>] jffs2_get_tree+0x25/0x30 [<ffffffffae9f358d>] vfs_get_tree+0x8d/0x2e0 [<ffffffffaea7a98f>] path_mount+0x50f/0x1e50 [<ffffffffaea7c3d7>] do_mount+0x107/0x130 [<ffffffffaea7c5c5>] __se_sys_mount+0x1c5/0x2f0 [<ffffffffaea7c917>] __x64_sys_mount+0xc7/0x160 [<ffffffffb10142f5>] do_syscall_64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423b04>] jffs2_sum_add_inode_mem+0x54/0x90 [<ffffffffb0f3bd44>] jffs2_scan_medium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423c34>] jffs2_sum_add_xattr_mem+0x54/0x90 [<ffffffffb0f3a24f>] jffs2_scan_medium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [<ffffffffae93be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffaf423cc4>] jffs2_sum_add_xref_mem+0x54/0x90 [<ffffffffb0f3b2e3>] jffs2_scan_medium.cold+0x3a20/0x4794 [...] -------------------------------------------- Therefore, we should call jffs2_sum_reset_collected(s) on exit to release the memory added in s. In addition, a new tag "out_buf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis) | ["https://git.kernel.org/stable/c/455f4a23490bfcbedc8e5c245c463a59b19e5ddd","https://git.kernel.org/stable/c/51dbb5e36d59f62e34d462b801c1068248149cfe","https://git.kernel.org/stable/c/52ba0ab4f0a606f02a6163493378989faa1ec10a","https://git.kernel.org/stable/c/82462324bf35b6b553400af1c1aa265069cee28f","https://git.kernel.org/stable/c/9b0c69182f09b70779817af4dcf89780955d5c4c","https://git.kernel.org/stable/c/9cdd3128874f5fe759e2c4e1360ab7fb96a8d1df","https://git.kernel.org/stable/c/b26bbc0c122cad038831f226a4cb4de702225e16","https://git.kernel.org/stable/c/b36bccb04e14cc0c1e2d0e92d477fe220314fad6","https://git.kernel.org/stable/c/e711913463af916d777a4873068f415f1fe2ad33"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49277 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_mount_fs If jffs2_build_filesystem() in jffs2_do_mount_fs() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffa493be24>] kmem_cache_alloc_trace+0x584/0x880 [<ffffffffa5423a06>] jffs2_sum_init+0x86/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] unreferenced object 0xffff88812c760000 (size 65536): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffffa493a449>] __kmalloc+0x6b9/0x910 [<ffffffffa5423a57>] jffs2_sum_init+0xd7/0x130 [<ffffffffa5400e58>] jffs2_do_mount_fs+0x798/0xac0 [<ffffffffa540acf3>] jffs2_do_fill_super+0x383/0xc30 [<ffffffffa540c00a>] jffs2_fill_super+0x2ea/0x4c0 [...] -------------------------------------------- This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem. | ["https://git.kernel.org/stable/c/0978e9af4559a171ac7a74a1b3ef21804b0a0fa9","https://git.kernel.org/stable/c/2a9d8184458562e6bf2f40d0e677fc85e2dd3834","https://git.kernel.org/stable/c/4392e8aeebc5a4f8073620bccba7de1b1f6d7c88","https://git.kernel.org/stable/c/5f34310d1376ca5b2ed798258def2c2ab3cc6699","https://git.kernel.org/stable/c/607d3aab7349f18e0d9dba4100d09d16fe27caca","https://git.kernel.org/stable/c/9a0f6610c7daedd2eace430beeb08a8b7ac80699","https://git.kernel.org/stable/c/c94128470e6fe53d9bd9d16d2d3271813f9d37af","https://git.kernel.org/stable/c/d051cef784de4d54835f6b6836d98a8f6935772c","https://git.kernel.org/stable/c/dbe0d0521eaa6a3d235517319266c539bb5c5112"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49280 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSD: prevent underflow in nfssvc_decode_writeargs() Smatch complains: fs/nfsd/nfsxdr.c:341 nfssvc_decode_writeargs() warn: no lower bound on 'args->len' Change the type to unsigned to prevent this issue. | ["https://git.kernel.org/stable/c/184416d4b98509fb4c3d8fc3d6dc1437896cc159","https://git.kernel.org/stable/c/1a33e0de60feda402d05ac8a6cf409c19ea3e0b3","https://git.kernel.org/stable/c/2764af8ce0bf03cc43ee4a11897cab96bde6caae","https://git.kernel.org/stable/c/413d8fefafe531a9442bb623e3fe292a38f88d65","https://git.kernel.org/stable/c/438068f4912183a59fcb6b7496a06437f7fd4e2b","https://git.kernel.org/stable/c/614a61e1592051cc42d3c38f899c9f7bdaad8a1d","https://git.kernel.org/stable/c/65e21cc042f4c1518c8c55283f53bc725b78419d","https://git.kernel.org/stable/c/85259340fc9bd54e3d567b41b881ecb4d0055da1","https://git.kernel.org/stable/c/9f0f048c1bfa7867d565a95fd8c28f4484ba1043"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49298 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: staging: rtl8712: fix uninit-value in r871xu_drv_init() When 'tmpU1b' returns from r8712_read8(padapter, EE_9346CR) is 0, 'mac[6]' will not be initialized. BUG: KMSAN: uninit-value in r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 r871xu_drv_init+0x2d54/0x3070 drivers/staging/rtl8712/usb_intf.c:541 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_set_configuration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0x13c/0x300 drivers/usb/core/generic.c:238 usb_probe_device+0x309/0x570 drivers/usb/core/driver.c:293 really_probe+0x653/0x14b0 drivers/base/dd.c:596 __driver_probe_device+0x3e9/0x530 drivers/base/dd.c:752 driver_probe_device drivers/base/dd.c:782 [inline] __device_attach_driver+0x79f/0x1120 drivers/base/dd.c:899 bus_for_each_drv+0x2d6/0x3f0 drivers/base/bus.c:427 __device_attach+0x593/0x8e0 drivers/base/dd.c:970 device_initial_probe+0x4a/0x60 drivers/base/dd.c:1017 bus_probe_device+0x17b/0x3e0 drivers/base/bus.c:487 device_add+0x1fff/0x26e0 drivers/base/core.c:3405 usb_new_device+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hub_port_connect drivers/usb/core/hub.c:5358 [inline] hub_port_connect_change drivers/usb/core/hub.c:5502 [inline] port_event drivers/usb/core/hub.c:5660 [inline] hub_event+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 process_one_work+0xdb6/0x1820 kernel/workqueue.c:2307 worker_thread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 Local variable mac created at: r871xu_drv_init+0x1771/0x3070 drivers/staging/rtl8712/usb_intf.c:394 usb_probe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396 KMSAN: uninit-value in r871xu_drv_init https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8 | ["https://git.kernel.org/stable/c/0458e5428e5e959d201a40ffe71d762a79ecedc4","https://git.kernel.org/stable/c/0b7371a22489cbb2e8e826ca03fb5ce92afb04fe","https://git.kernel.org/stable/c/277faa442fe0c59f418ac53f47a78e1266addd65","https://git.kernel.org/stable/c/52a0d88c328098b4e9fb8f2f3877fec0eff4104b","https://git.kernel.org/stable/c/70df04433fd351ba72bc635bd0b5fe443d9ac964","https://git.kernel.org/stable/c/76a964ad0ea8f2b10abd69a7532e174a28258283","https://git.kernel.org/stable/c/a6535d00a9d54ce1c2a8d86a85001ffb6844f9b2","https://git.kernel.org/stable/c/f36e754a1f0bafb9feeea63463de78080acb6de0","https://git.kernel.org/stable/c/ff727ab0b7d7a56b5ef281f12abd00c4b85894e9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49299 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc2: gadget: don't reset gadget's driver->bus UDC driver should not touch gadget's driver internals, especially it should not reset driver->bus. This wasn't harmful so far, but since commit fc274c1e9973 ("USB: gadget: Add a new bus for gadgets") gadget subsystem got it's own bus and messing with ->bus triggers the following NULL pointer dereference: dwc2 12480000.hsotg: bound driver g_ether 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000000 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: ... CPU: 0 PID: 620 Comm: modprobe Not tainted 5.18.0-rc5-next-20220504 #11862 Hardware name: Samsung Exynos (Flattened Device Tree) PC is at module_add_driver+0x44/0xe8 LR is at sysfs_do_create_link_sd+0x84/0xe0 ... Process modprobe (pid: 620, stack limit = 0x(ptrval)) ... module_add_driver from bus_add_driver+0xf4/0x1e4 bus_add_driver from driver_register+0x78/0x10c driver_register from usb_gadget_register_driver_owner+0x40/0xb4 usb_gadget_register_driver_owner from do_one_initcall+0x44/0x1e0 do_one_initcall from do_init_module+0x44/0x1c8 do_init_module from load_module+0x19b8/0x1b9c load_module from sys_finit_module+0xdc/0xfc sys_finit_module from ret_fast_syscall+0x0/0x54 Exception stack(0xf1771fa8 to 0xf1771ff0) ... dwc2 12480000.hsotg: new device is high-speed ---[ end trace 0000000000000000 ]--- Fix this by removing driver->bus entry reset. | ["https://git.kernel.org/stable/c/172cfc167c8ee6238f24f9c16efd598602af643c","https://git.kernel.org/stable/c/3120aac6d0ecd9accf56894aeac0e265f74d3d5a","https://git.kernel.org/stable/c/5127c0f365265bb69cd776ad6e4b872c309f3fa8","https://git.kernel.org/stable/c/547ebdc200b862dff761ff4890f66d8217c33316","https://git.kernel.org/stable/c/5b0c0298f7c3b57417f1729ec4071f76864b72dd","https://git.kernel.org/stable/c/bee8f9808a7e82addfc73a0973b16a8bb684205b","https://git.kernel.org/stable/c/d2159feb9d28ce496d77df98313ab454646372ac","https://git.kernel.org/stable/c/d232ca0bbc7d03144bad0ffd1792c3352bfd03fa","https://git.kernel.org/stable/c/efb15ff4a77fe053c941281775fefa91c87770e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49302 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: USB: host: isp116x: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. | ["https://git.kernel.org/stable/c/134a3408c2d3f7e23eb0e4556e0a2d9f36c2614e","https://git.kernel.org/stable/c/3592cfd8b848bf0c4d7740d78a87a7b8f6e1fa9a","https://git.kernel.org/stable/c/3825db88d8c704e7992b685618a03f82bffcf2ef","https://git.kernel.org/stable/c/7bffda1560a6f255fdf504e059fbbdb5d46b9e44","https://git.kernel.org/stable/c/804de302ada3544699c5f48c5314b249af76faa3","https://git.kernel.org/stable/c/82a101f14943f479fd190b1e5b40d91c77e2ac1b","https://git.kernel.org/stable/c/aca0cab0e9ed33b6371aafb519a6c38f2850ffc3","https://git.kernel.org/stable/c/c91a74b1f0f2d2d7e728742ae55e3ffe9ba7853d","https://git.kernel.org/stable/c/ee105039d3653444de4d3ede642383c92855dc1e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49307 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: synclink_gt: Fix null-pointer-dereference in slgt_clean() When the driver fails at alloc_hdlcdev(), and then we remove the driver module, we will get the following splat: [ 25.065966] general protection fault, probably for non-canonical address 0xdffffc0000000182: 0000 [#1] PREEMPT SMP KASAN PTI [ 25.066914] KASAN: null-ptr-deref in range [0x0000000000000c10-0x0000000000000c17] [ 25.069262] RIP: 0010:detach_hdlc_protocol+0x2a/0x3e0 [ 25.077709] Call Trace: [ 25.077924] <TASK> [ 25.078108] unregister_hdlc_device+0x16/0x30 [ 25.078481] slgt_cleanup+0x157/0x9f0 [synclink_gt] Fix this by checking whether the 'info->netdev' is a null pointer first. | ["https://git.kernel.org/stable/c/078212ad15dbd88840c82c97f12c93d83703c8fd","https://git.kernel.org/stable/c/1ceb4ca9543a8a788febf6bc8dad2e605e172d5e","https://git.kernel.org/stable/c/50c341f9a2adc4c32a8ad5a39eb99d9c4a419e0d","https://git.kernel.org/stable/c/689ca31c542687709ba21ec2195c1fbce34fd029","https://git.kernel.org/stable/c/8a95696bdc0e13f8980f05b54a3b9081963d1256","https://git.kernel.org/stable/c/ba08cbc5b53e151d0acf1930fb526fc65b7f3e65","https://git.kernel.org/stable/c/d68d5e68b7f64de7170f8e04dd9b995c36b2c71c","https://git.kernel.org/stable/c/ddd67751ab86c6a65f95c35293c42f85a42ac05d","https://git.kernel.org/stable/c/f6e07eb7ebec53ffe81fc2489589320fbe4a6b75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49314 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: Fix a possible resource leak in icom_probe When pci_read_config_dword failed, call pci_release_regions() and pci_disable_device() to recycle the resource previously allocated. | ["https://git.kernel.org/stable/c/23e155b51d403c0ccedc60c0d6c3c452afed07fe","https://git.kernel.org/stable/c/5f9b2e4ca88cab1a96b86ecd45544e488ca43faf","https://git.kernel.org/stable/c/8c014373f178a4f13a08e045ef63bdb23f62e892","https://git.kernel.org/stable/c/9a8305f357a8d03698fc7bc855ff9c6865d5486b","https://git.kernel.org/stable/c/a2df0b4d080cc770b4da7bff487048c803dfd07e","https://git.kernel.org/stable/c/cb7147afd328c07edeeee287710d8d96ac0459f5","https://git.kernel.org/stable/c/d703d912a985c1c5b50dd38c3181fc3540fa77cb","https://git.kernel.org/stable/c/ee157a79e7c82b01ae4c25de0ac75899801f322c","https://git.kernel.org/stable/c/f4c836d90da1ece88905d62ce2ce39a962f25d1a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49331 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths. | ["https://git.kernel.org/stable/c/3eca2c42daa4659965db6817479027cbc6df7899","https://git.kernel.org/stable/c/54423649bc0ed464b75807a7cf2857a5871f738f","https://git.kernel.org/stable/c/55904086041ba4ee4070187b36590f8f8d6df4cd","https://git.kernel.org/stable/c/593773088d615a46a42c97e01a0550d192bb7f74","https://git.kernel.org/stable/c/6fce324b530dd74750ad870699e33eeed1029ded","https://git.kernel.org/stable/c/996419e0594abb311fb958553809f24f38e7abbe","https://git.kernel.org/stable/c/d221ce54ce331c1a23be71eebf57f6a088632383","https://git.kernel.org/stable/c/db836b97464d44340b568e041fd24602858713f7","https://git.kernel.org/stable/c/f444ecd3f57f4ba5090fe8b6756933e37de4226e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49335 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/cs: make commands with 0 chunks illegal behaviour. Submitting a cs with 0 chunks, causes an oops later, found trying to execute the wrong userspace driver. MESA_LOADER_DRIVER_OVERRIDE=v3d glxinfo [172536.665184] BUG: kernel NULL pointer dereference, address: 00000000000001d8 [172536.665188] #PF: supervisor read access in kernel mode [172536.665189] #PF: error_code(0x0000) - not-present page [172536.665191] PGD 6712a0067 P4D 6712a0067 PUD 5af9ff067 PMD 0 [172536.665195] Oops: 0000 [#1] SMP NOPTI [172536.665197] CPU: 7 PID: 2769838 Comm: glxinfo Tainted: P O 5.10.81 #1-NixOS [172536.665199] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CROSSHAIR V FORMULA-Z, BIOS 2201 03/23/2015 [172536.665272] RIP: 0010:amdgpu_cs_ioctl+0x96/0x1ce0 [amdgpu] [172536.665274] Code: 75 18 00 00 4c 8b b2 88 00 00 00 8b 46 08 48 89 54 24 68 49 89 f7 4c 89 5c 24 60 31 d2 4c 89 74 24 30 85 c0 0f 85 c0 01 00 00 <48> 83 ba d8 01 00 00 00 48 8b b4 24 90 00 00 00 74 16 48 8b 46 10 [172536.665276] RSP: 0018:ffffb47c0e81bbe0 EFLAGS: 00010246 [172536.665277] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [172536.665278] RDX: 0000000000000000 RSI: ffffb47c0e81be28 RDI: ffffb47c0e81bd68 [172536.665279] RBP: ffff936524080010 R08: 0000000000000000 R09: ffffb47c0e81be38 [172536.665281] R10: ffff936524080010 R11: ffff936524080000 R12: ffffb47c0e81bc40 [172536.665282] R13: ffffb47c0e81be28 R14: ffff9367bc410000 R15: ffffb47c0e81be28 [172536.665283] FS: 00007fe35e05d740(0000) GS:ffff936c1edc0000(0000) knlGS:0000000000000000 [172536.665284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [172536.665286] CR2: 00000000000001d8 CR3: 0000000532e46000 CR4: 00000000000406e0 [172536.665287] Call Trace: [172536.665322] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665332] drm_ioctl_kernel+0xaa/0xf0 [drm] [172536.665338] drm_ioctl+0x201/0x3b0 [drm] [172536.665369] ? amdgpu_cs_find_mapping+0x110/0x110 [amdgpu] [172536.665372] ? selinux_file_ioctl+0x135/0x230 [172536.665399] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] [172536.665403] __x64_sys_ioctl+0x83/0xb0 [172536.665406] do_syscall_64+0x33/0x40 [172536.665409] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2018 | ["https://git.kernel.org/stable/c/15c3bcc9b5349d40207e5f8d4d799b8b4b7d13b8","https://git.kernel.org/stable/c/20b947e5a3c74c5084d661c097517a554989d462","https://git.kernel.org/stable/c/31ab27b14daaa75541a415c6794d6f3567fea44a","https://git.kernel.org/stable/c/70276460e914d560e96bfc208695a872fe9469c9","https://git.kernel.org/stable/c/7086a23890d255bb5761604e39174b20d06231a4","https://git.kernel.org/stable/c/8189f44270db1be78169e11eec51a3eeb980bc63","https://git.kernel.org/stable/c/aa25acbe96692e4bf8482311c293f72d8c6034c0","https://git.kernel.org/stable/c/be585921f29df5422a39c952d188b418ad48ffab","https://git.kernel.org/stable/c/c12984cdb077b9042d2dc20ca18cb16a87bcc774"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49351 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: altera: Fix refcount leak in altera_tse_mdio_create Every iteration of for_each_child_of_node() decrements the reference count of the previous node. When break from a for_each_child_of_node() loop, we need to explicitly call of_node_put() on the child node when not need anymore. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/11ec18b1d8d92b9df307d31950dcba0b3dd7283c","https://git.kernel.org/stable/c/1fd12298a0e0ca23478c715e672ee64c85670584","https://git.kernel.org/stable/c/4f850fe0a32c3f1e19b76996a3b1ca32637a14de","https://git.kernel.org/stable/c/5cd0e22fa11f4a21a8c09cc258f20b1474c95801","https://git.kernel.org/stable/c/803b217f1fb49a2dbb2123acdb45111b9c48b8be","https://git.kernel.org/stable/c/8174acbef87b8dd8bf3731eba2a5af1ac857e239","https://git.kernel.org/stable/c/96bf5ed057df2d157274d4e2079002f9a9404bb8","https://git.kernel.org/stable/c/a013fa884d8738ad8455aa1a843b8c9d80c6c833","https://git.kernel.org/stable/c/e31d9ba169860687dba19bdc8fccbfd34077f655"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49354 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ata: pata_octeon_cf: Fix refcount leak in octeon_cf_probe of_find_device_by_node() takes reference, we should use put_device() to release it when not need anymore. Add missing put_device() to avoid refcount leak. | ["https://git.kernel.org/stable/c/10d6bdf532902be1d8aa5900b3c03c5671612aa2","https://git.kernel.org/stable/c/19cb3ece14547cb1ca2021798aaf49a3f82643d1","https://git.kernel.org/stable/c/7bd85c5ba1687daf54e3b6907673c3604b1e75cf","https://git.kernel.org/stable/c/888312dc297a8a103f6371ef668c7e04f57a7679","https://git.kernel.org/stable/c/8d8ad067b90f231b8fdb14acee673ca4012f6045","https://git.kernel.org/stable/c/a4d3e5f1d7d4f8b5e3834fec0f057a762c55806b","https://git.kernel.org/stable/c/c9782e1b21bee4b783a64b2a91e7e71406c21a21","https://git.kernel.org/stable/c/d5a1e7f33c88780b279835d63665d7e38ccb671f","https://git.kernel.org/stable/c/fb2cb409b504bb3a69e65a17f3120328c8e50219"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49370 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: dmi-sysfs: Fix memory leak in dmi_sysfs_register_handle kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add() If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Fix this issue by calling kobject_put(). | ["https://git.kernel.org/stable/c/3ba359ebe914ac3f8c6c832b28007c14c39d3766","https://git.kernel.org/stable/c/660ba678f9998aca6db74f2dd912fa5124f0fa31","https://git.kernel.org/stable/c/985706bd3bbeffc8737bc05965ca8d24837bc7db","https://git.kernel.org/stable/c/a724634b2a49f6ff0177a9e19a5a92fc1545e1b7","https://git.kernel.org/stable/c/a9bfb37d6ba7c376b0d53337a4c5f5ff324bd725","https://git.kernel.org/stable/c/c66cc3c62870a27ea8f060a7e4c1ad8d26dd3f0d","https://git.kernel.org/stable/c/ec752973aa721ee281d5441e497364637c626c7b","https://git.kernel.org/stable/c/ed38d04342dfbe9e5aca745c8b5eb4188a74f0ef","https://git.kernel.org/stable/c/fdffa4ad8f6bf1ece877edfb807f2b2c729d8578"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49375 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtc: mt6397: check return value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. | ["https://git.kernel.org/stable/c/3867f0bbb94773d41e789257abec0d14f37da217","https://git.kernel.org/stable/c/58a729c55ce3a432eb827fdaa24c7909cd3b0a6b","https://git.kernel.org/stable/c/6ecd4d5c28408df36a1a6f0b1973f633c949ac1f","https://git.kernel.org/stable/c/79fa3f5758d8712df0678df98161f948fc4370e5","https://git.kernel.org/stable/c/82bfea344e8f7e9a0e0b1bf9af27552baa756620","https://git.kernel.org/stable/c/865051de2d9eaa50630e055b73921ceaf3c4a7fc","https://git.kernel.org/stable/c/d3b43eb505bffb8e4cdf6800c15660c001553fe6","https://git.kernel.org/stable/c/d77f28c1bc9d3043a52069fe42e4a26fbf961ebd","https://git.kernel.org/stable/c/da38e86d6cf6dd3bc65c602d998f357145aa1a0b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49381 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jffs2: fix memory leak in jffs2_do_fill_super If jffs2_iget() or d_make_root() in jffs2_do_fill_super() returns an error, we can observe the following kmemleak report: -------------------------------------------- unreferenced object 0xffff888105a65340 (size 64): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff859c45e5>] kmem_cache_alloc_trace+0x475/0x8a0 [<ffffffff86160146>] jffs2_sum_init+0x96/0x1a0 [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120 [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810 [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0 [...] unreferenced object 0xffff8881bd7f0000 (size 65536): comm "mount", pid 710, jiffies 4302851558 (age 58.239s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffff858579ba>] kmalloc_order+0xda/0x110 [<ffffffff85857a11>] kmalloc_order_trace+0x21/0x130 [<ffffffff859c2ed1>] __kmalloc+0x711/0x8a0 [<ffffffff86160189>] jffs2_sum_init+0xd9/0x1a0 [<ffffffff86140e25>] jffs2_do_mount_fs+0x745/0x2120 [<ffffffff86149fec>] jffs2_do_fill_super+0x35c/0x810 [<ffffffff8614aae9>] jffs2_fill_super+0x2b9/0x3b0 [...] -------------------------------------------- This is because the resources allocated in jffs2_sum_init() are not released. Call jffs2_sum_exit() to release these resources to solve the problem. | ["https://git.kernel.org/stable/c/28048a4cf3813b7cf5cc8cce629dfdc7951cb1c2","https://git.kernel.org/stable/c/3252d327f977b14663a10967f3b0930d6c325687","https://git.kernel.org/stable/c/4ba7bbeab8009faf3a726e565d98816593ddd5b0","https://git.kernel.org/stable/c/4da8763a3d2b684c773b72ed80fad40bc264bc40","https://git.kernel.org/stable/c/69295267c481545f636b69ff341b8db75aa136b9","https://git.kernel.org/stable/c/c14adb1cf70a984ed081c67e9d27bc3caad9537c","https://git.kernel.org/stable/c/cf9db013e167bc8fc2ecd7a13ed97a37df0c9dab","https://git.kernel.org/stable/c/d3a4fff1e7e408c32649030daa7c2c42a7e19a95","https://git.kernel.org/stable/c/ecc53e58596542791e82eff00702f8af7a313f70"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49389 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: usbip: fix a refcount leak in stub_probe() usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails after that, usb_put_dev() needs to be called to release the reference. Fix this by moving usb_put_dev() to sdev_free error path handling. Find this by code review. | ["https://git.kernel.org/stable/c/11c65408bd0ba1d9cd1307caa38169292de9cdfb","https://git.kernel.org/stable/c/247d3809e45a34d9e1a3a2bb7012e31ed8b46031","https://git.kernel.org/stable/c/2f0ae93ec33c8456cdfbf7876b80403a6318ebce","https://git.kernel.org/stable/c/51422046be504515eb5a591adf0f424b62f46804","https://git.kernel.org/stable/c/6bafee2f18af5e5ac125e42960bc65496d0e56a0","https://git.kernel.org/stable/c/8afb048800919d0ab10c57983940eba956339f21","https://git.kernel.org/stable/c/9ec4cbf1cc55d126759051acfe328d489c5d6e60","https://git.kernel.org/stable/c/bcbb795a9e78180d74c6ab21518da87e803dfdce","https://git.kernel.org/stable/c/f20d2d3b3364ce6525c050a8b6b4c54c8c19674d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49404 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Fix potential integer multiplication overflow errors When multiplying of different types, an overflow is possible even when storing the result in a larger type. This is because the conversion is done after the multiplication. So arithmetic overflow and thus in incorrect value is possible. Correct an instance of this in the inter packet delay calculation. Fix by ensuring one of the operands is u64 which will promote the other to u64 as well ensuring no overflow. | ["https://git.kernel.org/stable/c/06039d8afefdbac05bcea5f397188407eba2996d","https://git.kernel.org/stable/c/252f4afd4557a2e7075f793a5c80fe6dd9e9ee4a","https://git.kernel.org/stable/c/31dca00d0cc9f4133320d72eb7e3720badc6d6e6","https://git.kernel.org/stable/c/3f09ec80f115d2875d747ed28adc1773037e0f8b","https://git.kernel.org/stable/c/79c164e61f818054cd6012e9035701840d895c51","https://git.kernel.org/stable/c/8858284dd74906fa00f04f0252c75df4893a7959","https://git.kernel.org/stable/c/a89cb7ddf6a89bab6012e19da38b7cdb26175c19","https://git.kernel.org/stable/c/ef5ab2e48a5f9960e2352332b7cdb7064bb49032","https://git.kernel.org/stable/c/f93e91a0372c922c20d5bee260b0f43b4b8a1bee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49438 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: sparcspkr - fix refcount leak in bbc_beep_probe of_find_node_by_path() calls of_find_node_opts_by_path(), which returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. | ["https://git.kernel.org/stable/c/1124e39fea0e2fdb4202f95b716cb97cc7de7cc7","https://git.kernel.org/stable/c/2f51db16cb740ff90086189a1ef2581eab665591","https://git.kernel.org/stable/c/353bc58ac6c782d4dcde9136a91d1f90867938fe","https://git.kernel.org/stable/c/418b6a3e12f75638abc5673eb76cb32127d0ab13","https://git.kernel.org/stable/c/6e07ccc7d56130f760d23f67a70c45366c07debc","https://git.kernel.org/stable/c/73d6f42d8d86648bec2e73d34fe1648cb6d23e08","https://git.kernel.org/stable/c/bbc2b0ce6042dd3117827f10ea8cb67e0ab786da","https://git.kernel.org/stable/c/c8994b30d71d64d5dcc9bc0edbfdf367171aa96f","https://git.kernel.org/stable/c/f13064b0f2c651a3fbb0749932795c6fd21556a8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49447 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: hisi: Add missing of_node_put after of_find_compatible_node of_find_compatible_node will increment the refcount of the returned device_node. Calling of_node_put() to avoid the refcount leak | ["https://git.kernel.org/stable/c/21a3effe446dd6dc5eed7fe897c2f9b88c9a5d6d","https://git.kernel.org/stable/c/45d211668d33c49d73f5213e8c2b58468108647c","https://git.kernel.org/stable/c/46cb7868811d025c3d29c10d18b3422db1cf20d5","https://git.kernel.org/stable/c/9bc72e47d4630d58a840a66a869c56b29554cfe4","https://git.kernel.org/stable/c/a3265a9440030068547a20dfee646666f3ca5278","https://git.kernel.org/stable/c/cafaaae4bb9ce84a2791fa29bf6907a9466c3883","https://git.kernel.org/stable/c/dd4be8ecfb41a29e7c4e551b4e866157ce4a3429","https://git.kernel.org/stable/c/e109058165137ef42841abd989f080adfefa14fa","https://git.kernel.org/stable/c/f8da78b2bae1f54746647a2bb44f8bd6025c57af"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49450 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix listen() setting the bar too high for the prealloc rings AF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRC_CNT(). This means that listen(rxrpc_sock, 32) will cause an oops when the socket is closed because rxrpc_service_prealloc_one() allocated one too many calls and rxrpc_discard_prealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpc_release_calls_on_socket() then tries to abort them, but oopses because call->peer isn't yet set. Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to match the ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: <TASK> ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0 | ["https://git.kernel.org/stable/c/369de57492c4f1a42563c5a3bd365822ca3bfc79","https://git.kernel.org/stable/c/4a3a78b7918bdd723d8c7c9786522ca969bffcc4","https://git.kernel.org/stable/c/5b4826657d36c218e9f08e8d3223b0edce3de88f","https://git.kernel.org/stable/c/616f76498d5ddf26b997caf64a95cda3c8a55533","https://git.kernel.org/stable/c/61fb38cfbb1d54d3dafd0c25752f684b3cd00b32","https://git.kernel.org/stable/c/88e22159750b0d55793302eeed8ee603f5c1a95c","https://git.kernel.org/stable/c/91b34bf0409f43bb60453bab23c5beadd726d022","https://git.kernel.org/stable/c/b3a9b227d5e7467b8518160ff034ea22bb9de573","https://git.kernel.org/stable/c/e198f1930050e3115c80b67d9249f80f98a27c67"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49457 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: versatile: Add missing of_node_put in dcscb_init The device_node pointer is returned by of_find_compatible_node with refcount incremented. We should use of_node_put() to avoid the refcount leak. | ["https://git.kernel.org/stable/c/23b44f9c649bbef10b45fa33080cd8b4166800ae","https://git.kernel.org/stable/c/2d7b23db35254b7d46e852967090c64cdccf24da","https://git.kernel.org/stable/c/3c6006faed9aba5144b33176d061031a9be66954","https://git.kernel.org/stable/c/83c329b980bddbc8c6a3d287d91f2103a4d4a860","https://git.kernel.org/stable/c/a0fc05cd17617e63fc13ad0c01f3f0afd890d8ec","https://git.kernel.org/stable/c/bbdfb7d4f036118d36415a2575efa6f5246505ae","https://git.kernel.org/stable/c/d146e2a9864ade19914494de3fb520390b415d58","https://git.kernel.org/stable/c/d6de7b181c29cd4578ec139aafb5eac062abbe1b","https://git.kernel.org/stable/c/fcd1999ba97445a12cc394f5f42ffd9116bf0185"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49481 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: regulator: pfuze100: Fix refcount leak in pfuze_parse_regulators_dt of_node_get() returns a node with refcount incremented. Calling of_node_put() to drop the reference when not needed anymore. | ["https://git.kernel.org/stable/c/0be5d9da5743b9825a95baec85a67500b2c1d362","https://git.kernel.org/stable/c/49d785baeb91568332197be356d138e5e59c7ddb","https://git.kernel.org/stable/c/56ab0c01027492cd161c64148e1dc892c56887ad","https://git.kernel.org/stable/c/671be14fc31374b1a10a3abd93db6a8480838fc9","https://git.kernel.org/stable/c/6ca675f4abbc74bc991d154a1ecc8b384dc2aae4","https://git.kernel.org/stable/c/984cfef0675ed7398814e14af2c5323911723e1c","https://git.kernel.org/stable/c/9f564e29a51210a49df3d925117777c157a17d6d","https://git.kernel.org/stable/c/afaa7b933ef00a2d3262f4d1252087613fb5c06d","https://git.kernel.org/stable/c/b74c0dd9179d21b7260260e075d597b23970100c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49482 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: mxs-saif: Fix refcount leak in mxs_saif_probe of_parse_phandle() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. | ["https://git.kernel.org/stable/c/18b907ff0ae4bf20120aae1538f7156b9d08e3a7","https://git.kernel.org/stable/c/24491124406666bf0dcb9ee10c5575c6ce6a1730","https://git.kernel.org/stable/c/2a0da7641e1f17a744ac7b3f76471388c97b63dc","https://git.kernel.org/stable/c/2be84f73785fa9ed6443e3c5b158730266f1c2ee","https://git.kernel.org/stable/c/30d110ca703ce60162ec337aa564a3e4da30715f","https://git.kernel.org/stable/c/4e2a1bcc51bdebed48176f6e88c150f175983f9c","https://git.kernel.org/stable/c/c933829cbf3338b684869e6c4c8931abf5d68fbd","https://git.kernel.org/stable/c/d42601e93fce7802bb8d70dd59b60cfeefa20469","https://git.kernel.org/stable/c/d855505851ee8ba666eb204149b49f906130dc17"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49491 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: fix possible null-ptr-deref in vop_bind() It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. | ["https://git.kernel.org/stable/c/3451852312303d54a003c73bd0ae39cebb960bd5","https://git.kernel.org/stable/c/452922955df215a417c80d09dab72bbc667a1861","https://git.kernel.org/stable/c/6ff986e057bf28e2f7690dad410768b2270f9453","https://git.kernel.org/stable/c/769c53bb6116d0eaec0f1fe4ec4b27a74465cad1","https://git.kernel.org/stable/c/a9b4599665e437de8a1152799c34841b799a2e1c","https://git.kernel.org/stable/c/b54926bd558d97c888c3d2d87886f3c159d3254a","https://git.kernel.org/stable/c/ecfa52654d0c9c333c1fe1611f47105f6bce9591","https://git.kernel.org/stable/c/f8c242908ad15bbd604d3bcb54961b7d454c43f8","https://git.kernel.org/stable/c/fcd6a886443730c39170b8383411e52118aec0a3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49492 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags In nvme_alloc_admin_tags, the admin_q can be set to an error (typically -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which is checked immediately after the call. However, when we return the error message up the stack, to nvme_reset_work the error takes us to nvme_remove_dead_ctrl() nvme_dev_disable() nvme_suspend_queue(&dev->queues[0]). Here, we only check that the admin_q is non-NULL, rather than not an error or NULL, and begin quiescing a queue that never existed, leading to bad / NULL pointer dereference. | ["https://git.kernel.org/stable/c/54a4c1e47d1b2585e74920399455bd9abbfb2bd7","https://git.kernel.org/stable/c/7a28556082d1fbcbc599baf1c24252dfc73efefc","https://git.kernel.org/stable/c/8321b17789f614414206af07e17ce4751c95dc76","https://git.kernel.org/stable/c/8da2b7bdb47e94bbc4062a3978c708926bcb022c","https://git.kernel.org/stable/c/906c81dba8ee8057523859b5e1a2479e9fd34860","https://git.kernel.org/stable/c/9e649471b396fa0139d53919354ce1eace9b9a24","https://git.kernel.org/stable/c/af98940dd33c9f9e1beb4f71c0a39260100e2a65","https://git.kernel.org/stable/c/da42761181627e9bdc37d18368b827948a583929","https://git.kernel.org/stable/c/f76729662650cd7bc8f8194e057af381370349a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49495 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/ | ["https://git.kernel.org/stable/c/0978fcce91b90b561b8c82e7c492ba9fc8440eef","https://git.kernel.org/stable/c/2b3ed7547b1a052209da6c4ab886ffe0eed88c42","https://git.kernel.org/stable/c/4cd66a8016b872a153bf892fe4258cbc0dacf5b1","https://git.kernel.org/stable/c/6369dda4a2209142ab819f01d3d2076d81e3ebdd","https://git.kernel.org/stable/c/9cb1ee33efccb8b107ee04b7b3441820de3fd2da","https://git.kernel.org/stable/c/9f5495a5c51c1d11c6ffc13aa2befffec0c2651a","https://git.kernel.org/stable/c/a36e506711548df923ceb7ec9f6001375be799a5","https://git.kernel.org/stable/c/c1bfacf0daf25a5fc7d667399d6ff2dffda84cd8","https://git.kernel.org/stable/c/d9cb951d11a4ace4de5c50b1178ad211de17079e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49514 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path. | ["https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531","https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e","https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30","https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a","https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5","https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a","https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6","https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113","https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49538 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: jack: Access input_dev under mutex It is possible when using ASoC that input_dev is unregistered while calling snd_jack_report, which causes NULL pointer dereference. In order to prevent this serialize access to input_dev using mutex lock. | ["https://git.kernel.org/stable/c/1b6a6fc5280e97559287b61eade2d4b363e836f2","https://git.kernel.org/stable/c/582aea6084cc59fec881204f026816d1219f2348","https://git.kernel.org/stable/c/5cc6f623f4818c7d7e9e966a45ebf324901ca9c5","https://git.kernel.org/stable/c/74bab3bcf422593c582e47130aa8eb41ebb2dc09","https://git.kernel.org/stable/c/8487a88136d54a1a4d3f26f1399685db648ab879","https://git.kernel.org/stable/c/9e6a73b0c0f2014eb89249fb1640c5a3d58221c4","https://git.kernel.org/stable/c/c093b62c40027c21d649c5534ad7aa3605a99b00","https://git.kernel.org/stable/c/e2b8681769f6e205382f026b907d28aa5ec9d59a","https://git.kernel.org/stable/c/f68bed124c7699e23ffb4ce4fcc84671e9193cde"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49544 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipw2x00: Fix potential NULL dereference in libipw_xmit() crypt and crypt->ops could be null, so we need to checking null before dereference | ["https://git.kernel.org/stable/c/167affc11781d7d35c4c3a7630a549ac74dd0b21","https://git.kernel.org/stable/c/1ff6b0727c8988f25eeb670b6c038c1120bb58dd","https://git.kernel.org/stable/c/48d4a820fd33f012e5f63735a59d15b5a3882882","https://git.kernel.org/stable/c/528d2023ccf4748fd542582955236c1634a7d293","https://git.kernel.org/stable/c/5f7ea274e88c0eeffe6bd6dbf6cf5c479d356af6","https://git.kernel.org/stable/c/8fb1b9beb085bb767ae43e441db5ac6fcd66a04d","https://git.kernel.org/stable/c/98d1dc32f890642476dbb78ed3437a456bf421b0","https://git.kernel.org/stable/c/b4628e0d3754ab2fc98ee6e3d21851ba45798077","https://git.kernel.org/stable/c/e8366bbabe1d207cf7c5b11ae50e223ae6fc278b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26633 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim() syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken. Reading frag_off can only be done if we pulled enough bytes to skb->head. Currently we might access garbage. [1] BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098 __pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655 pskb_may_pull_reason include/linux/skbuff.h:2673 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408 ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline] ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137 ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243 dst_output include/net/dst.h:451 [inline] ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155 ip6_send_skb net/ipv6/ip6_output.c:1952 [inline] ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972 rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582 rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920 inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendms ---truncated--- | ["https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee","https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c","https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d","https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2","https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183","https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087","https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198","https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd","https://git.kernel.org/stable/c/135414f300c5db995e2a2f3bf0f455de9d014aee","https://git.kernel.org/stable/c/3f15ba3dc14e6ee002ea01b4faddc3d49200377c","https://git.kernel.org/stable/c/4329426cf6b8e22b798db2331c7ef1dd2a9c748d","https://git.kernel.org/stable/c/62a1fedeb14c7ac0947ef33fadbabd35ed2400a2","https://git.kernel.org/stable/c/687c5d52fe53e602e76826dbd4d7af412747e183","https://git.kernel.org/stable/c/ba8d904c274268b18ef3dc11d3ca7b24a96cb087","https://git.kernel.org/stable/c/d375b98e0248980681e5e56b712026174d617198","https://git.kernel.org/stable/c/da23bd709b46168f7dfc36055801011222b076cd","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241220-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50285 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit. | ["https://git.kernel.org/stable/c/0a77d947f599b1f39065015bec99390d0c0022ee","https://git.kernel.org/stable/c/1f993777275cbd8f74765c4f9d9285cb907c9be5","https://git.kernel.org/stable/c/e257ac6fe138623cf59fca8898abdf659dbc8356"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21672 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: afs: Fix merge preference rule failure condition syzbot reported a lock held when returning to userspace[1]. This is because if argc is less than 0 and the function returns directly, the held inode lock is not released. Fix this by store the error in ret and jump to done to clean up instead of returning directly. [dh: Modified Lizhi Xu's original patch to make it honour the error code from afs_split_string()] [1] WARNING: lock held when returning to user space! 6.13.0-rc3-syzkaller-00209-g499551201b5f #0 Not tainted ------------------------------------------------ syz-executor133/5823 is leaving the kernel with locks still held! 1 lock held by syz-executor133/5823: #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: inode_lock include/linux/fs.h:818 [inline] #0: ffff888071cffc00 (&sb->s_type->i_mutex_key#9){++++}-{4:4}, at: afs_proc_addr_prefs_write+0x2bb/0x14e0 fs/afs/addr_prefs.c:388 | ["https://git.kernel.org/stable/c/17a4fde81d3a7478d97d15304a6d61094a10c2e3","https://git.kernel.org/stable/c/22be1d90a6211c88dd093b25d1f3aa974d0d9f9d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21912 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: rcar: Use raw_spinlock to protect register access Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access. [ 4.239592] ============================= [ 4.239595] [ BUG: Invalid wait context ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 is trying to lock: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] other info that might help us debug this: [ 4.239643] context-{5:5} [ 4.239646] 5 locks held by kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz [ 4.304082] stack backtrace: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 4.304097] Workqueue: async async_run_entry_fn [ 4.304106] Call trace: [ 4.304110] show_stack+0x14/0x20 (C) [ 4.304122] dump_stack_lvl+0x6c/0x90 [ 4.304131] dump_stack+0x14/0x1c [ 4.304138] __lock_acquire+0xdfc/0x1584 [ 4.426274] lock_acquire+0x1c4/0x33c [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: link resume succeeded after 1 retries [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_for_each_drv+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] worker_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_from_fork+0x10/0x20 | ["https://git.kernel.org/stable/c/3e300913c42041e81c5b17a970c4e078086ff2d1","https://git.kernel.org/stable/c/51ef3073493e2a25dced05fdd59dfb059e7e284d","https://git.kernel.org/stable/c/7c1f36f9c9aca507d317479a3d3388150ae40a87","https://git.kernel.org/stable/c/b42c84f9e4ec5bc2885e7fd80c79ec0352f5d2af","https://git.kernel.org/stable/c/c10365031f16514a29c812cd909085a6e4ea4b61","https://git.kernel.org/stable/c/f02c41f87cfe61440c18bf77d1ef0a884b9ee2b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21951 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlock There are multiple places from where the recovery work gets scheduled asynchronously. Also, there are multiple places where the caller waits synchronously for the recovery to be completed. One such place is during the PM shutdown() callback. If the device is not alive during recovery_work, it will try to reset the device using pci_reset_function(). This function internally will take the device_lock() first before resetting the device. By this time, if the lock has already been acquired, then recovery_work will get stalled while waiting for the lock. And if the lock was already acquired by the caller which waits for the recovery_work to be completed, it will lead to deadlock. This is what happened on the X1E80100 CRD device when the device died before shutdown() callback. Driver core calls the driver's shutdown() callback while holding the device_lock() leading to deadlock. And this deadlock scenario can occur on other paths as well, like during the PM suspend() callback, where the driver core would hold the device_lock() before calling driver's suspend() callback. And if the recovery_work was already started, it could lead to deadlock. This is also observed on the X1E80100 CRD. So to fix both issues, use pci_try_reset_function() in recovery_work. This function first checks for the availability of the device_lock() before trying to reset the device. If the lock is available, it will acquire it and reset the device. Otherwise, it will return -EAGAIN. If that happens, recovery_work will fail with the error message "Recovery failed" as not much could be done. | ["https://git.kernel.org/stable/c/1f9eb7078bc6b5fb5cbfbcb37c4bc01685332b95","https://git.kernel.org/stable/c/62505657475c245c9cd46e42ac01026d1e61f027","https://git.kernel.org/stable/c/7746f3bb8917fccb4571a576f3837d80fc513054","https://git.kernel.org/stable/c/7a5ffadd54fe2662f5c99cdccf30144d060376f7","https://git.kernel.org/stable/c/985d3cf56d8745ca637deee273929e01df449f85","https://git.kernel.org/stable/c/a321d163de3d8aa38a6449ab2becf4b1581aed96"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49568 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: Don't null dereference ops->destroy A KVM device cleanup happens in either of two callbacks: 1) destroy() which is called when the VM is being destroyed; 2) release() which is called when a device fd is closed. Most KVM devices use 1) but Book3s's interrupt controller KVM devices (XICS, XIVE, XIVE-native) use 2) as they need to close and reopen during the machine execution. The error handling in kvm_ioctl_create_device() assumes destroy() is always defined which leads to NULL dereference as discovered by Syzkaller. This adds a checks for destroy!=NULL and adds a missing release(). This is not changing kvm_destroy_devices() as devices with defined release() should have been removed from the KVM devices list by then. | ["https://git.kernel.org/stable/c/170465715a60cbb7876e6b961b21bd3225469da8","https://git.kernel.org/stable/c/3616776bc51cd3262bb1be60cc01c72e0a1959cf","https://git.kernel.org/stable/c/d4a5a79b780891c5cbdfdc6124d46fdf8d13dba1","https://git.kernel.org/stable/c/e8bc2427018826e02add7b0ed0fc625a60390ae5","https://git.kernel.org/stable/c/e91665fbbf3ccb268b268a7d71a6513538d813ac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49125 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/sprd: fix potential NULL dereference 'drm' could be null in sprd_drm_shutdown, and drm_warn maybe dereference it, remove this warning log. v1 -> v2: - Split checking platform_get_resource() return value to a separate patch - Use dev_warn() instead of removing the warning log | ["https://git.kernel.org/stable/c/8668658aebb0a19d877d5a81c004baf716c4aaa6","https://git.kernel.org/stable/c/c3acc8db1bc221604e2db9807f01d8a44b97a64d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49134 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum: Guard against invalid local ports When processing events generated by the device's firmware, the driver protects itself from events reported for non-existent local ports, but not for the CPU port (local port 0), which exists, but does not have all the fields as any local port. This can result in a NULL pointer dereference when trying access 'struct mlxsw_sp_port' fields which are not initialized for CPU port. Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware") already handled such issue by bailing early when processing a PUDE event reported for the CPU port. Generalize the approach by moving the check to a common function and making use of it in all relevant places. | ["https://git.kernel.org/stable/c/4cad27ba2e5a5843a7fab5aa30de2b8e8c3db3a8","https://git.kernel.org/stable/c/bcdfd615f83b4bd04678109bf18022d1476e4bbf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49177 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwrng: cavium - fix NULL but dereferenced coccicheck error Fix following coccicheck warning: ./drivers/char/hw_random/cavium-rng-vf.c:182:17-20: ERROR: pdev is NULL but dereferenced. | ["https://git.kernel.org/stable/c/e47b12f9415169eceda6770fcf45802e0c8d2a66","https://git.kernel.org/stable/c/e6205ad58a7ac194abfb33897585b38687d797fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49317 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: avoid infinite loop to flush node pages xfstests/generic/475 can give EIO all the time which give an infinite loop to flush node page like below. Let's avoid it. [16418.518551] Call Trace: [16418.518553] ? dm_submit_bio+0x48/0x400 [16418.518574] ? submit_bio_checks+0x1ac/0x5a0 [16418.525207] __submit_bio+0x1a9/0x230 [16418.525210] ? kmem_cache_alloc+0x29e/0x3c0 [16418.525223] submit_bio_noacct+0xa8/0x2b0 [16418.525226] submit_bio+0x4d/0x130 [16418.525238] __submit_bio+0x49/0x310 [f2fs] [16418.525339] ? bio_add_page+0x6a/0x90 [16418.525344] f2fs_submit_page_bio+0x134/0x1f0 [f2fs] [16418.525365] read_node_page+0x125/0x1b0 [f2fs] [16418.525388] __get_node_page.part.0+0x58/0x3f0 [f2fs] [16418.525409] __get_node_page+0x2f/0x60 [f2fs] [16418.525431] f2fs_get_dnode_of_data+0x423/0x860 [f2fs] [16418.525452] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [16418.525458] ? __mod_memcg_state.part.0+0x2a/0x30 [16418.525465] ? __mod_memcg_lruvec_state+0x27/0x40 [16418.525467] ? __xa_set_mark+0x57/0x70 [16418.525472] f2fs_do_write_data_page+0x10e/0x7b0 [f2fs] [16418.525493] f2fs_write_single_data_page+0x555/0x830 [f2fs] [16418.525514] ? sysvec_apic_timer_interrupt+0x4e/0x90 [16418.525518] ? asm_sysvec_apic_timer_interrupt+0x12/0x20 [16418.525523] f2fs_write_cache_pages+0x303/0x880 [f2fs] [16418.525545] ? blk_flush_plug_list+0x47/0x100 [16418.525548] f2fs_write_data_pages+0xfd/0x320 [f2fs] [16418.525569] do_writepages+0xd5/0x210 [16418.525648] filemap_fdatawrite_wbc+0x7d/0xc0 [16418.525655] filemap_fdatawrite+0x50/0x70 [16418.525658] f2fs_sync_dirty_inodes+0xa4/0x230 [f2fs] [16418.525679] f2fs_write_checkpoint+0x16d/0x1720 [f2fs] [16418.525699] ? ttwu_do_wakeup+0x1c/0x160 [16418.525709] ? ttwu_do_activate+0x6d/0xd0 [16418.525711] ? __wait_for_common+0x11d/0x150 [16418.525715] kill_f2fs_super+0xca/0x100 [f2fs] [16418.525733] deactivate_locked_super+0x3b/0xb0 [16418.525739] deactivate_super+0x40/0x50 [16418.525741] cleanup_mnt+0x139/0x190 [16418.525747] __cleanup_mnt+0x12/0x20 [16418.525749] task_work_run+0x6d/0xa0 [16418.525765] exit_to_user_mode_prepare+0x1ad/0x1b0 [16418.525771] syscall_exit_to_user_mode+0x27/0x50 [16418.525774] do_syscall_64+0x48/0xc0 [16418.525776] entry_SYSCALL_64_after_hwframe+0x44/0xae | ["https://git.kernel.org/stable/c/a7b8618aa2f0f926ce85f2486ac835a85c753ca7","https://git.kernel.org/stable/c/bd47ea5d776d8b524fb6f60de3240f95603901dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49484 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector Fix possible NULL pointer dereference in mt7915_mac_fill_rx_vector routine if the chip does not support dbdc and the hw reports band_idx set to 1. | ["https://git.kernel.org/stable/c/268e8ef187eb8780d021b0e4f5ffa92dee5c4983","https://git.kernel.org/stable/c/62fdc974894eec80d678523458cf99bbdb887e22"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49516 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ice: always check VF VSI pointer values The ice_get_vf_vsi function can return NULL in some cases, such as if handling messages during a reset where the VSI is being removed and recreated. Several places throughout the driver do not bother to check whether this VSI pointer is valid. Static analysis tools maybe report issues because they detect paths where a potentially NULL pointer could be dereferenced. Fix this by checking the return value of ice_get_vf_vsi everywhere. | ["https://git.kernel.org/stable/c/baeb705fd6a7245cc1fa69ed991a9cffdf44a174","https://git.kernel.org/stable/c/e7be3877589d539c52e5d1d23a625f889b541b9d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49529 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/pm: fix the null pointer while the smu is disabled It needs to check if the pp_funcs is initialized while release the context, otherwise it will trigger null pointer panic while the software smu is not enabled. [ 1109.404555] BUG: kernel NULL pointer dereference, address: 0000000000000078 [ 1109.404609] #PF: supervisor read access in kernel mode [ 1109.404638] #PF: error_code(0x0000) - not-present page [ 1109.404657] PGD 0 P4D 0 [ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G OEL 5.16.0-custom #1 [ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu] [ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 <49> 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f [ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282 [ 1109.405203] RAX: 0000000000000000 RBX: ffff9796b1c14600 RCX: 0000000002862007 [ 1109.405229] RDX: ffff97968591c8c0 RSI: 0000000000000001 RDI: ffff9796a3700000 [ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60 [ 1109.405286] R10: 0000000000000000 R11: ffff979688d9db90 R12: 0000000000000001 [ 1109.405316] R13: ffff9796a3700000 R14: 0000000000000000 R15: ffff9796a3708fc0 [ 1109.405345] FS: 00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:0000000000000000 [ 1109.405378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1109.405400] CR2: 0000000000000078 CR3: 000000000a394000 CR4: 00000000000506e0 [ 1109.405434] Call Trace: [ 1109.405445] <TASK> [ 1109.405456] ? delete_object_full+0x1d/0x20 [ 1109.405480] amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu] [ 1109.405698] amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu] [ 1109.405911] amdgpu_ctx_do_release+0x71/0x80 [amdgpu] [ 1109.406121] amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu] [ 1109.406327] ? _raw_spin_unlock+0x1a/0x30 [ 1109.406354] ? drm_gem_handle_delete+0x81/0xb0 [drm] [ 1109.406400] ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu] [ 1109.406609] drm_ioctl_kernel+0xb6/0x140 [drm] | ["https://git.kernel.org/stable/c/49ec3441aa5e5940f3e82dd2f0205b9c856e399d","https://git.kernel.org/stable/c/eea5c7b3390c6e006ba4cbd906447dd8cea8cfbf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49534 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT There is a potential memory leak in lpfc_ignore_els_cmpl() and lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT (lpfc_rcv_plogi()'s login_mbox). Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(), and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for service parameters. For lpfc_els_rsp_reject() failure, free both the ctx_buf for service parameters and the login_mbox. | ["https://git.kernel.org/stable/c/672d1cb40551ea9c95efad43ab6d45e4ab4e015f","https://git.kernel.org/stable/c/c00df0f34a6d5e14da379f96ea67e501ce67b002"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21833 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer. | ["https://git.kernel.org/stable/c/60f030f7418d3f1d94f2fb207fe3080e1844630b","https://git.kernel.org/stable/c/df96876be3b064aefc493f760e0639765d13ed0d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50111 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context Unaligned access exception can be triggered in irq-enabled context such as user mode, in this case do_ale() may call get_user() which may cause sleep. Then we will get: BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G W 6.12.0-rc1+ #1723 Tainted: [W]=WARN Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000 9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000 9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890 ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500 000000000000020c 000000000000000a 0000000000000000 0000000000000003 00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260 0000000000000000 0000000000000000 9000000005437650 90000000055d5000 0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000 0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec 00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d ... Call Trace: [<9000000003803964>] show_stack+0x64/0x1a0 [<9000000004c57464>] dump_stack_lvl+0x74/0xb0 [<9000000003861ab4>] __might_resched+0x154/0x1a0 [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60 [<9000000004c58118>] do_ale+0x78/0x180 [<9000000003801bc8>] handle_ale+0x128/0x1e0 So enable IRQ if unaligned access exception is triggered in irq-enabled context to fix it. | ["https://git.kernel.org/stable/c/69cc6fad5df4ce652d969be69acc60e269e5eea1","https://git.kernel.org/stable/c/8915ed160dbd32b5ef5864df9a9fc11db83a77bb","https://git.kernel.org/stable/c/afbfb3568d78082078acc8bb2b29bb47af87253c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23004 | Medium | fixed |
|
In the Linux kernel before 5.19, drivers/gpu/drm/arm/malidp_planes.c misinterprets the get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/15342f930ebebcfe36f2415049736a77d7d2e045","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1073 | Medium | N/A | A memory corruption flaw was found in the Linux kernel’s human interface device (HID) subsystem in how a user inserts a malicious USB device. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["http://www.openwall.com/lists/oss-security/2023/11/05/2","http://www.openwall.com/lists/oss-security/2023/11/05/3","https://bugzilla.redhat.com/show_bug.cgi?id=2173403","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/id=b12fece4c64857e5fab4290bf01b2e0317a88456","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/osssecurity/2023/01/17/3","http://www.openwall.com/lists/oss-security/2023/11/05/2","http://www.openwall.com/lists/oss-security/2023/11/05/3","https://bugzilla.redhat.com/show_bug.cgi?id=2173403","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/id=b12fece4c64857e5fab4290bf01b2e0317a88456","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/osssecurity/2023/01/17/3"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0646 | High | fixed |
|
An out-of-bounds memory write flaw was found in the Linux kernel’s Transport Layer Security functionality in how a user calls a function splice with a ktls socket as the destination. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0850","https://access.redhat.com/errata/RHSA-2024:0851","https://access.redhat.com/errata/RHSA-2024:0876","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1251","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1368","https://access.redhat.com/errata/RHSA-2024:1377","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2024-0646","https://bugzilla.redhat.com/show_bug.cgi?id=2253908","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0850","https://access.redhat.com/errata/RHSA-2024:0851","https://access.redhat.com/errata/RHSA-2024:0876","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1251","https://access.redhat.com/errata/RHSA-2024:1253","https://access.redhat.com/errata/RHSA-2024:1268","https://access.redhat.com/errata/RHSA-2024:1269","https://access.redhat.com/errata/RHSA-2024:1278","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1368","https://access.redhat.com/errata/RHSA-2024:1377","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2024-0646","https://bugzilla.redhat.com/show_bug.cgi?id=2253908","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c5a595000e267","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-42753 | High | fixed |
|
An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the `h->nets` array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7539","https://access.redhat.com/errata/RHSA-2023:7558","https://access.redhat.com/errata/RHSA-2024:0089","https://access.redhat.com/errata/RHSA-2024:0113","https://access.redhat.com/errata/RHSA-2024:0134","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0346","https://access.redhat.com/errata/RHSA-2024:0347","https://access.redhat.com/errata/RHSA-2024:0371","https://access.redhat.com/errata/RHSA-2024:0376","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0402","https://access.redhat.com/errata/RHSA-2024:0403","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:0999","https://access.redhat.com/security/cve/CVE-2023-42753","https://bugzilla.redhat.com/show_bug.cgi?id=2239843","https://seclists.org/oss-sec/2023/q3/216","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7539","https://access.redhat.com/errata/RHSA-2023:7558","https://access.redhat.com/errata/RHSA-2024:0089","https://access.redhat.com/errata/RHSA-2024:0113","https://access.redhat.com/errata/RHSA-2024:0134","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0346","https://access.redhat.com/errata/RHSA-2024:0347","https://access.redhat.com/errata/RHSA-2024:0371","https://access.redhat.com/errata/RHSA-2024:0376","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0402","https://access.redhat.com/errata/RHSA-2024:0403","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:0999","https://access.redhat.com/security/cve/CVE-2023-42753","https://bugzilla.redhat.com/show_bug.cgi?id=2239843","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://seclists.org/oss-sec/2023/q3/216","https://www.openwall.com/lists/oss-security/2023/09/22/10"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3625 | High | fixed |
|
A vulnerability was found in Linux Kernel. It has been classified as critical. This affects the function devlink_param_set/devlink_param_get of the file net/core/devlink.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier VDB-211929 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211929","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=6b4db2e528f650c7fb712961aac36455468d5902","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211929"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3630 | Medium | N/A | A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects some unknown processing of the file fs/fscache/cookie.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211931. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=fb24771faf72a2fd62b3b6287af3c610c3ec9cf1","https://vuldb.com/?id.211931","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=fb24771faf72a2fd62b3b6287af3c610c3ec9cf1","https://vuldb.com/?id.211931"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22038 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate zero num_subauth before sub_auth is accessed Access psid->sub_auth[psid->num_subauth - 1] without checking if num_subauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure num_subauth != 0 before sub_auth is accessed. | ["https://git.kernel.org/stable/c/0e36a3e080d6d8bd7a34e089345d043da4ac8283","https://git.kernel.org/stable/c/3ac65de111c686c95316ade660f8ba7aea3cd3cc","https://git.kernel.org/stable/c/56de7778a48560278c334077ace7b9ac4bfb2fd1","https://git.kernel.org/stable/c/68c6c3142bfcdb049839d40a9a59ebe8ea865002","https://git.kernel.org/stable/c/bf21e29d78cd2c2371023953d9c82dfef82ebb36","https://git.kernel.org/stable/c/c8bfe1954a0b89e7b29b3a3e7f4c5e0ebd295e20"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49740 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads This patch fixes slab-out-of-bounds reads in brcmfmac that occur in brcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count value of channel specifications provided by the device is greater than the length of 'list->element[]', decided by the size of the 'list' allocated with kzalloc(). The patch adds checks that make the functions free the buffer and return -EINVAL if that is the case. Note that the negative return is handled by the caller, brcmf_setup_wiphybands() or brcmf_cfg80211_attach(). Found by a modified version of syzkaller. Crash Report from brcmf_construct_chaninfo(): ================================================================== BUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430 Read of size 4 at addr ffff888115f24600 by task kworker/0:2/1896 CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G W O 5.14.0+ #132 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x57/0x7d print_address_description.constprop.0.cold+0x93/0x334 kasan_report.cold+0x83/0xdf brcmf_setup_wiphybands+0x1238/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 Allocated by task 1896: kasan_save_stack+0x1b/0x40 __kasan_kmalloc+0x7c/0x90 kmem_cache_alloc_trace+0x19e/0x330 brcmf_setup_wiphybands+0x290/0x1430 brcmf_cfg80211_attach+0x2118/0x3fd0 brcmf_attach+0x389/0xd40 brcmf_usb_probe+0x12de/0x1690 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_set_configuration+0x984/0x1770 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 bus_for_each_drv+0x123/0x1a0 __device_attach+0x207/0x330 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 usb_new_device.cold+0x463/0xf66 hub_event+0x10d5/0x3330 process_one_work+0x873/0x13e0 worker_thread+0x8b/0xd10 kthread+0x379/0x450 ret_from_fork+0x1f/0x30 The buggy address belongs to the object at ffff888115f24000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1536 bytes inside of 2048-byte region [ffff888115f24000, ffff888115f24800) Memory state around the buggy address: ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ================================================================== Crash Report from brcmf_enable_bw40_2g(): ========== ---truncated--- | ["https://git.kernel.org/stable/c/4920ab131b2dbae7464b72bdcac465d070254209","https://git.kernel.org/stable/c/9cf5e99c1ae1a85286a76c9a970202750538394c","https://git.kernel.org/stable/c/b2e412879595821ff1b5545cbed5f108fba7f5b6","https://git.kernel.org/stable/c/e4991910f15013db72f6ec0db7038ea67a57052e","https://git.kernel.org/stable/c/f06de1bb6d61f0c18b0213bbc6298960037f9d42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49152 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: XArray: Fix xas_create_range() when multi-order entry present If there is already an entry present that is of order >= XA_CHUNK_SHIFT when we call xas_create_range(), xas_create_range() will misinterpret that entry as a node and dereference xa_node->parent, generally leading to a crash that looks something like this: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0 RIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline] RIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725 It's deterministically reproducable once you know what the problem is, but producing it in a live kernel requires khugepaged to hit a race. While the problem has been present since xas_create_range() was introduced, I'm not aware of a way to hit it before the page cache was converted to use multi-index entries. | ["https://git.kernel.org/stable/c/18f13edf3424b3b61814b69d5269b2e14584800c","https://git.kernel.org/stable/c/1ac49c8fd49fdf53d3cd8b77eb8ffda08d7fbe22","https://git.kernel.org/stable/c/29968329b926d238e3107ec071a250397555d264","https://git.kernel.org/stable/c/3e2852eda19ee1a400cd809d7a9322680f34a262","https://git.kernel.org/stable/c/3e3c658055c002900982513e289398a1aad4a488","https://git.kernel.org/stable/c/7521a97b1929042604bef6859f62fa8b4bbc077b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49295 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nbd: call genl_unregister_family() first in nbd_cleanup() Otherwise there may be race between module removal and the handling of netlink command, which can lead to the oops as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000098 Oops: 0002 [#1] SMP PTI CPU: 1 PID: 31299 Comm: nbd-client Tainted: G E 5.14.0-rc4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:down_write+0x1a/0x50 Call Trace: start_creating+0x89/0x130 debugfs_create_dir+0x1b/0x130 nbd_start_device+0x13d/0x390 [nbd] nbd_genl_connect+0x42f/0x748 [nbd] genl_family_rcv_msg_doit.isra.0+0xec/0x150 genl_rcv_msg+0xe5/0x1e0 netlink_rcv_skb+0x55/0x100 genl_rcv+0x29/0x40 netlink_unicast+0x1a8/0x250 netlink_sendmsg+0x21b/0x430 ____sys_sendmsg+0x2a4/0x2d0 ___sys_sendmsg+0x81/0xc0 __sys_sendmsg+0x62/0xb0 __x64_sys_sendmsg+0x1f/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: nbd(E-) | ["https://git.kernel.org/stable/c/013a79f1b5c89290e2e97f1ebf14b14e0cf5fe5c","https://git.kernel.org/stable/c/06c4da89c24e7023ea448cadf8e9daf06a0aae6e","https://git.kernel.org/stable/c/1be608e1ee1f222464b2856bda9b85ab5184a33e","https://git.kernel.org/stable/c/3d5da1ffba3388c2ae2e6c598855a4d887d3bf79","https://git.kernel.org/stable/c/6f505bbb8063fd3a238a4239d2d8c165e5279f6f","https://git.kernel.org/stable/c/8a1435c862ea09b06be7acda325128dc08458e25","https://git.kernel.org/stable/c/c0868f6e728c3c28bef0e8bee89d2daf86a8bbca","https://git.kernel.org/stable/c/cbeafa7a79d08ecdb55f8f1d41a11323d0f709db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1205 | Medium | N/A | A NULL pointer dereference flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system. | ["https://access.redhat.com/security/cve/CVE-2022-1205","https://bugzilla.redhat.com/show_bug.cgi?id=2071047","https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0","https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009","https://www.openwall.com/lists/oss-security/2022/04/02/4","https://access.redhat.com/security/cve/CVE-2022-1205","https://bugzilla.redhat.com/show_bug.cgi?id=2071047","https://github.com/torvalds/linux/commit/82e31755e55fbcea6a9dfaae5fe4860ade17cbc0","https://github.com/torvalds/linux/commit/fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009","https://www.openwall.com/lists/oss-security/2022/04/02/4"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49003 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme: fix SRCU protection of nvme_ns_head list Walking the nvme_ns_head siblings list is protected by the head's srcu in nvme_ns_head_submit_bio() but not nvme_mpath_revalidate_paths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees. Hold the head's srcu lock in nvme_mpath_revalidate_paths() and synchronize with the srcu, not the global RCU, in nvme_ns_remove(). Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != get_capacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic). [37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x86_64 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvme_scan_work [nvme_core] [37314.299783] RIP: 0010:nvme_mpath_revalidate_paths+0x26/0xb0 [nvme_core] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvme_update_ns_info+0x1ac/0x250 [nvme_core] [37315.892075] nvme_validate_or_alloc_ns+0x2ff/0xa00 [nvme_core] [37315.961871] ? __blk_mq_free_request+0x6b/0x90 [37316.015021] nvme_scan_work+0x151/0x240 [nvme_core] [37316.073371] process_one_work+0x1a7/0x360 [37316.121318] ? create_worker+0x1a0/0x1a0 [37316.168227] worker_thread+0x30/0x390 [37316.212024] ? create_worker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? set_kthread_struct+0x50/0x50 [37316.347590] ret_from_fork+0x35/0x40 [37316.390360] Modules linked in: nvme_rdma nvme_tcp(X) nvme_fabrics nvme_core netconsole iscsi_tcp libiscsi_tcp dm_queue_length dm_service_time nf_conntrack_netlink br_netfilter bridge stp llc overlay nft_chain_nat ipt_MASQUERADE nf_nat xt_addrtype xt_CT nft_counter xt_state xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment xt_multiport nft_compat nf_tables libcrc32c nfnetlink dm_multipath tg3 rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm intel_rapl_msr iTCO_wdt iTCO_vendor_support dcdbas intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ipmi_ssif kvm irqbypass crct10dif_pclmul crc32_pclmul mlx5_ib ghash_clmulni_intel ib_uverbs rapl intel_cstate intel_uncore ib_core ipmi_si joydev mei_me pcspkr ipmi_devintf mei lpc_ich wmi ipmi_msghandler acpi_power_meter ex ---truncated--- | ["https://git.kernel.org/stable/c/5b566d09ab1b975566a53f9c5466ee260d087582","https://git.kernel.org/stable/c/787d81d4eb150e443e5d1276c6e8f03cfecc2302","https://git.kernel.org/stable/c/899d2a05dc14733cfba6224083c6b0dd5a738590"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45919 | High | fixed |
|
An issue was discovered in the Linux kernel through 6.0.10. In drivers/media/dvb-core/dvb_ca_en50221.c, a use-after-free can occur is there is a disconnect after an open, because of the lack of a wait_event. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd","https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u","https://security.netapp.com/advisory/ntap-20230113-0008/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=280a8ab81733da8bc442253c700a52c4c0886ffd","https://lore.kernel.org/linux-media/20221121063308.GA33821%40ubuntu/T/#u","https://security.netapp.com/advisory/ntap-20230113-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2961 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s PLP Rose functionality in the way a user triggers a race condition by calling bind while simultaneously triggering the rose_bind() function. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://access.redhat.com/security/cve/CVE-2022-2961","https://security.netapp.com/advisory/ntap-20230214-0004/","https://access.redhat.com/security/cve/CVE-2022-2961","https://security.netapp.com/advisory/ntap-20230214-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-51781 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.6.8. atalk_ioctl in net/appletalk/ddp.c has a use-after-free because of an atalk_recvmsg race condition. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.8","https://github.com/torvalds/linux/commit/189ff16722ee36ced4d2a2469d4ab65a8fee4198","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22062 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sctp: add mutual exclusion in proc_sctp_do_udp_port() We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start() or risk a crash as syzbot reported: Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653 Call Trace: <TASK> udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] | ["https://git.kernel.org/stable/c/10206302af856791fbcc27a33ed3c3eb09b2793d","https://git.kernel.org/stable/c/386507cb6fb7cdef598ddcb3f0fa37e6ca9e789d","https://git.kernel.org/stable/c/65ccb2793da7401772a3ffe85355c831b313c59f","https://git.kernel.org/stable/c/b3598f53211ba1025485306de2733bdd241311a3","https://git.kernel.org/stable/c/d3d7675d77622f6ca1aae14c51f80027b36283f8","https://git.kernel.org/stable/c/e5178bfc55b3a78000f0f8298e7ade88783ce581","https://git.kernel.org/stable/c/efb8cb487be8f4ba6aaef616011d702d6a083ed1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22081 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix a couple integer overflows on 32bit systems On 32bit systems the "off + sizeof(struct NTFS_DE)" addition can have an integer wrapping issue. Fix it by using size_add(). | ["https://git.kernel.org/stable/c/0538f52410b619737e663167b6a2b2d0bc1a589d","https://git.kernel.org/stable/c/0922d86a7a6032cb1694eab0b44b861bd33ba8d5","https://git.kernel.org/stable/c/0dfe700fbd3525f30a36ffbe390a5b9319bd009a","https://git.kernel.org/stable/c/1a14e9718a19d2e88de004a1360bfd7a86ed1395","https://git.kernel.org/stable/c/284c9549386e9883855fb82b730303bb2edea9de","https://git.kernel.org/stable/c/4d0f4f42922a832388a0c2fe5204c0a1037ff786","https://git.kernel.org/stable/c/5ad414f4df2294b28836b5b7b69787659d6aa708"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-38152 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Clear table_sz when rproc_shutdown There is case as below could trigger kernel dump: Use U-Boot to start remote processor(rproc) with resource table published to a fixed address by rproc. After Kernel boots up, stop the rproc, load a new firmware which doesn't have resource table ,and start rproc. When starting rproc with a firmware not have resource table, `memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will trigger dump, because rproc->cache_table is set to NULL during the last stop operation, but rproc->table_sz is still valid. This issue is found on i.MX8MP and i.MX9. Dump as below: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __pi_memcpy_generic+0x110/0x22c lr : rproc_start+0x88/0x1e0 Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19c Clear rproc->table_sz to address the issue. | ["https://git.kernel.org/stable/c/068f6648ff5b0c7adeb6c363fae7fb188aa178fa","https://git.kernel.org/stable/c/2df19f5f6f72da6f6ebab7cdb3a3b9f7686bb476","https://git.kernel.org/stable/c/6e66bca8cd51ebedd5d32426906a38e4a3c69c5f","https://git.kernel.org/stable/c/7c6bb82a6f3da6ab2d3fbea03901482231708b98","https://git.kernel.org/stable/c/8e0fd2a3b9852ac3cf540edb06ccc0153b38b5af","https://git.kernel.org/stable/c/e6015ca453b82ec54aec9682dcc38773948fcc48","https://git.kernel.org/stable/c/efdde3d73ab25cef4ff2d06783b0aad8b093c0e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3077 | Medium | fixed |
|
A buffer overflow vulnerability was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way it handled the I2C_SMBUS_BLOCK_PROC_CALL case (via the ioctl I2C_SMBUS) with malicious input data. This flaw could allow a local user to crash the system. | ["https://github.com/torvalds/linux/commit/690b2549b19563ec5ad53e5c82f6a944d910086e","https://github.com/torvalds/linux/commit/690b2549b19563ec5ad53e5c82f6a944d910086e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1204 | Medium | fixed |
|
A use-after-free flaw was found in the Linux kernel’s Amateur Radio AX.25 protocol functionality in the way a user connects with the protocol. This flaw allows a local user to crash the system. | ["https://access.redhat.com/security/cve/CVE-2022-1204","https://bugzilla.redhat.com/show_bug.cgi?id=2071051","https://security-tracker.debian.org/tracker/CVE-2022-1204","https://www.openwall.com/lists/oss-security/2022/04/02/2","https://access.redhat.com/security/cve/CVE-2022-1204","https://bugzilla.redhat.com/show_bug.cgi?id=2071051","https://security-tracker.debian.org/tracker/CVE-2022-1204","https://www.openwall.com/lists/oss-security/2022/04/02/2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56751 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: release nexthop on device removal The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test: unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6 ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0 While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info. Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown(). Tested running: ./pmtu.sh cleanup_ipv6_exception in a tight loop for more than 400 iterations with no spat, running an unpatched kernel I observed a splat every ~10 iterations. | ["https://git.kernel.org/stable/c/0e4c6faaef8a24b762a24ffb767280e263ef8e10","https://git.kernel.org/stable/c/43e25adc80269f917d2a195f0d59f74cdd182955","https://git.kernel.org/stable/c/77aa9855a878fb43f547ddfbda3127a1e88ad31a","https://git.kernel.org/stable/c/a3c3f8a4d025acc8c857246ec2b812c59102487a","https://git.kernel.org/stable/c/b2f26a27ea3f72f75d18330f76f5d1007c791848","https://git.kernel.org/stable/c/eb02688c5c45c3e7af7e71f036a7144f5639cbfe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2380 | Medium | fixed |
|
The Linux kernel was found vulnerable out of bounds memory access in the drivers/video/fbdev/sm712fb.c:smtcfb_read() function. The vulnerability could result in local attackers being able to crash the kernel. | ["https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next\u0026id=bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8","https://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git/commit/?h=for-next\u0026id=bd771cf5c4254511cc4abb88f3dab3bd58bdf8e8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52607 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. | ["https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532","https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611","https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b","https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7","https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1","https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071","https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e","https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74","https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532","https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611","https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b","https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7","https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1","https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced0d3b071","https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e","https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4155 | Medium | fixed |
|
A data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS filesystem otherwise not accessible to them. | ["https://access.redhat.com/security/cve/CVE-2021-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2034813","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79","https://security-tracker.debian.org/tracker/CVE-2021-4155","https://www.openwall.com/lists/oss-security/2022/01/10/1","https://access.redhat.com/security/cve/CVE-2021-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2034813","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79","https://security-tracker.debian.org/tracker/CVE-2021-4155","https://www.openwall.com/lists/oss-security/2022/01/10/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-57950 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominator defaults to 1 [WHAT & HOW] Variables, used as denominators and maybe not assigned to other values, should be initialized to non-zero to avoid DIVIDE_BY_ZERO, as reported by Coverity. (cherry picked from commit e2c4c6c10542ccfe4a0830bb6c9fd5b177b7bbb7) | ["https://git.kernel.org/stable/c/36b23e3baf9129d5b6c3a3a85b6b7ffb75ae287c","https://git.kernel.org/stable/c/c9d6afb4f9c338049662d27d169fba7dd60e337d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21696 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: clear uffd-wp PTE/PMD state on mremap() When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROT_WRITE) to trigger a warning in page_table_check_pte_flags() due to setting the pte to writable while uffd-wp is still set. Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VM_UFFD_WP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths. | ["https://git.kernel.org/stable/c/0cef0bb836e3cfe00f08f9606c72abd72fe78ca3","https://git.kernel.org/stable/c/310ac886d68de661c3a334198d8604b722d7fdf8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26828 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: fix underflow in parse_server_interfaces() In this loop, we step through the buffer and after each item we check if the size_left is greater than the minimum size we need. However, the problem is that "bytes_left" is type ssize_t while sizeof() is type size_t. That means that because of type promotion, the comparison is done as an unsigned and if we have negative bytes left the loop continues instead of ending. | ["https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512","https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204","https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301","https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308","https://git.kernel.org/stable/c/7190353835b4a219abb70f90b06cdcae97f11512","https://git.kernel.org/stable/c/cffe487026be13eaf37ea28b783d9638ab147204","https://git.kernel.org/stable/c/df2af9fdbc4ddde18a3371c4ca1a86596e8be301","https://git.kernel.org/stable/c/f7ff1c89fb6e9610d2b01c1821727729e6609308"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52530 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential key use-after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn't happen since it's only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). | ["https://git.kernel.org/stable/c/2408f491ff998d674707725eadc47d8930aced09","https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36","https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b","https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d","https://git.kernel.org/stable/c/e8a834eb09bb95c2bf9c76f1a28ecef7d8c439d0","https://git.kernel.org/stable/c/e8e599a635066c50ac214c3e10858f1d37e03022","https://git.kernel.org/stable/c/2f4e16e39e4f5e78248dd9e51276a83203950b36","https://git.kernel.org/stable/c/31db78a4923ef5e2008f2eed321811ca79e7f71b","https://git.kernel.org/stable/c/65c72a7201704574dace708cbc96a8f367b1491d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26622 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tomoyo: fix UAF write bug in tomoyo_write_control() Since tomoyo_write_control() updates head->write_buf when write() of long lines is requested, we need to fetch head->write_buf after head->io_sem is held. Otherwise, concurrent write() requests can cause use-after-free-write and double-free problems. | ["https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f","https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815","https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824","https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711","https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc","https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee","https://git.kernel.org/stable/c/2caa605079488da9601099fbda460cfc1702839f","https://git.kernel.org/stable/c/2f03fc340cac9ea1dc63cbf8c93dd2eb0f227815","https://git.kernel.org/stable/c/3bfe04c1273d30b866f4c7c238331ed3b08e5824","https://git.kernel.org/stable/c/6edefe1b6c29a9932f558a898968a9fcbeec5711","https://git.kernel.org/stable/c/7d930a4da17958f869ef679ee0e4a8729337affc","https://git.kernel.org/stable/c/a23ac1788e2c828c097119e9a3178f0b7e503fee","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2235 | High | fixed |
|
A use-after-free vulnerability in the Linux Kernel Performance Events system can be exploited to achieve local privilege escalation. The perf_group_detach function did not check the event's siblings' attach_state before calling add_event_to_groups(), but remove_on_exec made it possible to call list_del_event() on before detaching from their group, making it possible to use a dangling pointer causing a use-after-free vulnerability. We recommend upgrading past commit fd0815f632c24878e325821943edccc7fde947a2. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2","https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fd0815f632c24878e325821943edccc7fde947a2","https://kernel.dance/fd0815f632c24878e325821943edccc7fde947a2","https://security.netapp.com/advisory/ntap-20230609-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26689 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error was caught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed. In same file, in "handle_cap_grant()" refcount is decremented by this line - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error. | ["https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77","https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc","https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214","https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7","https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef","https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139","https://git.kernel.org/stable/c/70e329b440762390258a6fe8c0de93c9fdd56c77","https://git.kernel.org/stable/c/7958c1bf5b03c6f1f58e724dbdec93f8f60b96fc","https://git.kernel.org/stable/c/8180d0c27b93a6eb60da1b08ea079e3926328214","https://git.kernel.org/stable/c/ae20db45e482303a20e56f2db667a9d9c54ac7e7","https://git.kernel.org/stable/c/cda4672da1c26835dcbd7aec2bfed954eda9b5ef","https://git.kernel.org/stable/c/f3f98d7d84b31828004545e29fd7262b9f444139","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52474 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4. Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those SDMA requests complete. | ["https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127","https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc","https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d","https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678","https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80","https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844","https://git.kernel.org/stable/c/00cbce5cbf88459cd1aa1d60d0f1df15477df127","https://git.kernel.org/stable/c/7e6010f79b58f45b204cf18aa58f4b73c3f30adc","https://git.kernel.org/stable/c/9c4c6512d7330b743c4ffd18bd999a86ca26db0d","https://git.kernel.org/stable/c/a2bd706ab63509793b5cd5065e685b7ef5cba678","https://git.kernel.org/stable/c/c76cb8f4bdf26d04cfa5485a93ce297dba5e6a80","https://git.kernel.org/stable/c/dce59b5443700fbd0d2433ec6e4d4cf063448844"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52509 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop(). | ["https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705","https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89","https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6","https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5","https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965","https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82","https://git.kernel.org/stable/c/105abd68ad8f781985113aee2e92e0702b133705","https://git.kernel.org/stable/c/3971442870713de527684398416970cf025b4f89","https://git.kernel.org/stable/c/616761cf9df9af838c0a1a1232a69322a9eb67e6","https://git.kernel.org/stable/c/65d34cfd4e347054eb4193bc95d9da7eaa72dee5","https://git.kernel.org/stable/c/6f6fa8061f756aedb93af12a8a5d3cf659127965","https://git.kernel.org/stable/c/db9aafa19547833240f58c2998aed7baf414dc82"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26782 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mptcp: fix double-free on socket dismantle when MPTCP server accepts an incoming connection, it clones its listener socket. However, the pointer to 'inet_opt' for the new socket has the same value as the original one: as a consequence, on program exit it's possible to observe the following splat: BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0 Free of addr ffff888485950880 by task swapper/25/0 CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609 Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0 07/26/2013 Call Trace: <IRQ> dump_stack_lvl+0x32/0x50 print_report+0xca/0x620 kasan_report_invalid_free+0x64/0x90 __kasan_slab_free+0x1aa/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 rcu_do_batch+0x34e/0xd90 rcu_core+0x559/0xac0 __do_softirq+0x183/0x5a4 irq_exit_rcu+0x12d/0x170 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x16/0x20 RIP: 0010:cpuidle_enter_state+0x175/0x300 Code: 30 00 0f 84 1f 01 00 00 83 e8 01 83 f8 ff 75 e5 48 83 c4 18 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc fb 45 85 ed <0f> 89 60 ff ff ff 48 c1 e5 06 48 c7 43 18 00 00 00 00 48 83 44 2b RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202 RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000 RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588 RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080 R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0 R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80 cpuidle_enter+0x4a/0xa0 do_idle+0x310/0x410 cpu_startup_entry+0x51/0x60 start_secondary+0x211/0x270 secondary_startup_64_no_verify+0x184/0x18b </TASK> Allocated by task 6853: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 __kmalloc+0x1eb/0x450 cipso_v4_sock_setattr+0x96/0x360 netlbl_sock_setattr+0x132/0x1f0 selinux_netlbl_socket_post_create+0x6c/0x110 selinux_socket_post_create+0x37b/0x7f0 security_socket_post_create+0x63/0xb0 __sock_create+0x305/0x450 __sys_socket_create.part.23+0xbd/0x130 __sys_socket+0x37/0xb0 __x64_sys_socket+0x6f/0xb0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 6858: kasan_save_stack+0x1c/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x12c/0x1f0 kfree+0xed/0x2e0 inet_sock_destruct+0x54f/0x8b0 __sk_destruct+0x48/0x5b0 subflow_ulp_release+0x1f0/0x250 tcp_cleanup_ulp+0x6e/0x110 tcp_v4_destroy_sock+0x5a/0x3a0 inet_csk_destroy_sock+0x135/0x390 tcp_fin+0x416/0x5c0 tcp_data_queue+0x1bc8/0x4310 tcp_rcv_state_process+0x15a3/0x47b0 tcp_v4_do_rcv+0x2c1/0x990 tcp_v4_rcv+0x41fb/0x5ed0 ip_protocol_deliver_rcu+0x6d/0x9f0 ip_local_deliver_finish+0x278/0x360 ip_local_deliver+0x182/0x2c0 ip_rcv+0xb5/0x1c0 __netif_receive_skb_one_core+0x16e/0x1b0 process_backlog+0x1e3/0x650 __napi_poll+0xa6/0x500 net_rx_action+0x740/0xbb0 __do_softirq+0x183/0x5a4 The buggy address belongs to the object at ffff888485950880 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes inside of 64-byte region [ffff888485950880, ffff8884859508c0) The buggy address belongs to the physical page: page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950 flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006 raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888485950780: fa fb fb ---truncated--- | ["https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c","https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e","https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc","https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582","https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85","https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e","https://git.kernel.org/stable/c/10048689def7e40a4405acda16fdc6477d4ecc5c","https://git.kernel.org/stable/c/4a4eeb6912538c2d0b158e8d11b62d96c1dada4e","https://git.kernel.org/stable/c/85933e80d077c9ae2227226beb86c22f464059cc","https://git.kernel.org/stable/c/ce0809ada38dca8d6d41bb57ab40494855c30582","https://git.kernel.org/stable/c/d93fd40c62397326046902a2c5cb75af50882a85","https://git.kernel.org/stable/c/f74362a004225df935863dea6eb7d82daaa5b16e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52482 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too. | ["https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96","https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d","https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4","https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d","https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37","https://git.kernel.org/stable/c/6ce2f297a7168274547d0b5aea6c7c16268b8a96","https://git.kernel.org/stable/c/a5ef7d68cea1344cf524f04981c2b3f80bedbb0d","https://git.kernel.org/stable/c/cf43b304b6952b549d58feabc342807b334f03d4","https://git.kernel.org/stable/c/e7ea043bc3f19473561c08565047b3f1671bf35d","https://git.kernel.org/stable/c/f090a8b4d2e3ec6f318d6fdab243a2edc5a8cc37","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52614 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG in the case where we don't have enough space to write the full transition table. Also document in the ABI that this function can return -EFBIG error. | ["https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c","https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4","https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f","https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c","https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8","https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87","https://git.kernel.org/stable/c/087de000e4f8c878c81d9dd3725f00a1d292980c","https://git.kernel.org/stable/c/08e23d05fa6dc4fc13da0ccf09defdd4bbc92ff4","https://git.kernel.org/stable/c/796d3fad8c35ee9df9027899fb90ceaeb41b958f","https://git.kernel.org/stable/c/8a7729cda2dd276d7a3994638038fb89035b6f2c","https://git.kernel.org/stable/c/a979f56aa4b93579cf0e4265ae04d7e9300fd3e8","https://git.kernel.org/stable/c/eaef4650fa2050147ca25fd7ee43bc0082e03c87","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52452 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix accesses to uninit stack slots Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons. This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it. Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead. This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue. A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv. | ["https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19","https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529","https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde","https://git.kernel.org/stable/c/0954982db8283016bf38e9db2da5adf47a102e19","https://git.kernel.org/stable/c/6b4a64bafd107e521c01eec3453ce94a3fb38529","https://git.kernel.org/stable/c/fbcf372c8eda2290470268e0afb5ab5d5f5d5fde"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52591 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: reiserfs: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. | ["https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc","https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed","https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c","https://git.kernel.org/stable/c/17e1361cb91dc1325834da95d2ab532959d2debc","https://git.kernel.org/stable/c/49db9b1b86a82448dfaf3fcfefcf678dee56c8ed","https://git.kernel.org/stable/c/c04c162f82ac403917780eb6d1654694455d4e7c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-26242 | High | N/A | afu_mmio_region_get_by_offset in drivers/fpga/dfl-afu-region.c in the Linux kernel through 6.1.12 has an integer overflow. | ["https://bugzilla.suse.com/show_bug.cgi?id=1208518","https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com","https://security.netapp.com/advisory/ntap-20230406-0002/","https://bugzilla.suse.com/show_bug.cgi?id=1208518","https://patchwork.kernel.org/project/linux-fpga/patch/20230206054326.89323-1-k1rh4.lee%40gmail.com","https://security.netapp.com/advisory/ntap-20230406-0002/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52441 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix out of bounds in init_smb2_rsp_hdr() If client send smb2 negotiate request and then send smb1 negotiate request, init_smb2_rsp_hdr is called for smb1 negotiate request since need_neg is set to false. This patch ignore smb1 packets after ->need_neg is set to false. | ["https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc","https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b","https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b","https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f","https://git.kernel.org/stable/c/330d900620dfc9893011d725b3620cd2ee0bc2bc","https://git.kernel.org/stable/c/536bb492d39bb6c080c92f31e8a55fe9934f452b","https://git.kernel.org/stable/c/5c0df9d30c289d6b9d7d44e2a450de2f8e3cf40b","https://git.kernel.org/stable/c/aa669ef229ae8dd779da9caa24e254964545895f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4611 | Medium | fixed |
|
A use-after-free flaw was found in mm/mempolicy.c in the memory management subsystem in the Linux Kernel. This issue is caused by a race between mbind() and VMA-locked page fault, and may allow a local attacker to crash the system or lead to a kernel information leak. | ["https://access.redhat.com/security/cve/CVE-2023-4611","https://bugzilla.redhat.com/show_bug.cgi?id=2227244","https://www.spinics.net/lists/stable-commits/msg310136.html","https://access.redhat.com/security/cve/CVE-2023-4611","https://bugzilla.redhat.com/show_bug.cgi?id=2227244","https://www.spinics.net/lists/stable-commits/msg310136.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52597 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: fix setting of fpc register kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. | ["https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3","https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99","https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7","https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18","https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1","https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2","https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55","https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f","https://git.kernel.org/stable/c/0671f42a9c1084db10d68ac347d08dbf6689ecb3","https://git.kernel.org/stable/c/150a3a3871490e8c454ffbac2e60abeafcecff99","https://git.kernel.org/stable/c/2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7","https://git.kernel.org/stable/c/3a04410b0bc7e056e0843ac598825dd359246d18","https://git.kernel.org/stable/c/5e63c9ae8055109d805aacdaf2a4fe2c3b371ba1","https://git.kernel.org/stable/c/732a3bea7aba5b15026ea42d14953c3425cc7dc2","https://git.kernel.org/stable/c/b988b1bb0053c0dcd26187d29ef07566a565cf55","https://git.kernel.org/stable/c/c87d7d910775a025e230fd6359b60627e392460f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-1312 | Medium | fixed |
|
A use-after-free flaw was found in the Linux kernel's Memory Management subsystem when a user wins two races at the same time with a fail in the mas_prev_slot function. This issue could allow a local user to crash the system. | ["https://access.redhat.com/security/cve/CVE-2024-1312","https://bugzilla.redhat.com/show_bug.cgi?id=2225569","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3\u0026id=657b5146955eba331e01b9a6ae89ce2e716ba306","https://access.redhat.com/security/cve/CVE-2024-1312","https://bugzilla.redhat.com/show_bug.cgi?id=2225569","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/memory.c?h=v6.8-rc3\u0026id=657b5146955eba331e01b9a6ae89ce2e716ba306"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-28356 | Medium | fixed |
|
In the Linux kernel before 5.17.1, a refcount leak bug was found in net/llc/af_llc.c. | ["http://www.openwall.com/lists/oss-security/2022/04/06/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1","https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220506-0006/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","http://www.openwall.com/lists/oss-security/2022/04/06/1","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.1","https://github.com/torvalds/linux/commit/764f4eb6846f5475f1244767d24d25dd86528a4a","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220506-0006/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-40133 | Medium | fixed |
|
A use-after-free(UAF) vulnerability was found in function 'vmw_execbuf_tie_context' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=2075","https://bugzilla.openanolis.cn/show_bug.cgi?id=2075"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-47233 | Medium | N/A | The brcm80211 component in the Linux kernel through 6.5.10 has a brcmf_cfg80211_detach use-after-free in the device unplugging (disconnect the USB by hotplug) code. For physically proximate attackers with local access, this "could be exploited in a real world scenario." This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c. | ["https://bugzilla.suse.com/show_bug.cgi?id=1216702","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/","https://marc.info/?l=linux-kernel\u0026m=169907678011243\u0026w=2","https://bugzilla.suse.com/show_bug.cgi?id=1216702","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f7352557a35ab7888bc7831411ec8a3cbe20d78","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/all/20231104054709.716585-1-zyytlz.wz%40163.com/","https://marc.info/?l=linux-kernel\u0026m=169907678011243\u0026w=2"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21943 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: aggregator: protect driver attr handlers against module unload Both new_device_store and delete_device_store touch module global resources (e.g. gpio_aggregator_lock). To prevent race conditions with module unload, a reference needs to be held. Add try_module_get() in these handlers. For new_device_store, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpio_aggregator_idr but platform_device_register has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: <TASK> ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]--- | ["https://git.kernel.org/stable/c/12f65d1203507f7db3ba59930fe29a3b8eee9945","https://git.kernel.org/stable/c/56281a76b805b5ac61feb5d580139695a22f87f0","https://git.kernel.org/stable/c/807789018186cf508ceb3a1f8f02935cd195717b","https://git.kernel.org/stable/c/8fb07fb1bba91d45846ed8605c3097fe67a7d54c","https://git.kernel.org/stable/c/9334c88fc2fbc6836b307d269fcc1744c69701c0","https://git.kernel.org/stable/c/d99dc8f7ea01ee1b21306e0eda8eb18a4af80db6","https://git.kernel.org/stable/c/fd6aa1f8cbe0979eb66ac32ebc231bf0b10a2117"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-39188 | Medium | fixed |
|
An issue was discovered in include/asm-generic/tlb.h in the Linux kernel before 5.19. Because of a race condition (unmap_mapping_range versus munmap), a device driver can free a page while it still has stale TLB entries. This only occurs in situations with VM_PFNMAP VMAs. | ["https://bugs.chromium.org/p/project-zero/issues/detail?id=2329","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257","https://bugs.chromium.org/p/project-zero/issues/detail?id=2329","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://github.com/torvalds/linux/commit/b67fbebd4cf980aecbcc750e1462128bffe8ae15","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/stable/CAG48ez3SEqOPcPCYGHVZv4iqEApujD5VtM3Re-tCKLDEFdEdbg%40mail.gmail.com/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21947 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix type confusion via race condition when using ipc_msg_send_request req->handle is allocated using ksmbd_acquire_id(&ipc_ida), based on ida_alloc. req->handle from ksmbd_ipc_login_request and FSCTL_PIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse. | ["https://git.kernel.org/stable/c/1e8833c03a38e1d5d5df6484e3f670a2fd38fb76","https://git.kernel.org/stable/c/3cb2b2e41541fe6f9cc55ca22d4c0bd260498aea","https://git.kernel.org/stable/c/6321bbda4244b93802d61cfe0887883aae322f4b","https://git.kernel.org/stable/c/76861630b29e51373e73e7b00ad0d467b6941162","https://git.kernel.org/stable/c/e2ff19f0b7a30e03516e6eb73b948e27a55bc9d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4394 | Medium | fixed |
|
A use-after-free flaw was found in btrfs_get_dev_args_from_path in fs/btrfs/volumes.c in btrfs file-system in the Linux Kernel. This flaw allows a local attacker with special privileges to cause a system crash or leak internal kernel information | ["https://access.redhat.com/security/cve/CVE-2023-4394","https://bugzilla.redhat.com/show_bug.cgi?id=2219263","https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-4394","https://bugzilla.redhat.com/show_bug.cgi?id=2219263","https://patchwork.kernel.org/project/linux-btrfs/patch/20220815151606.3479183-1-r33s3n6@gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23039 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 6.2.0-rc2. drivers/tty/vcc.c has a race condition and resultant use-after-free if a physically proximate attacker removes a VCC device while calling open(), aka a race condition between vcc_open() and vcc_remove(). | ["https://lkml.org/lkml/2023/1/1/169","https://lkml.org/lkml/2023/1/1/169"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48635 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fsdax: Fix infinite loop in dax_iomap_rw() I got an infinite loop and a WARNING report when executing a tail command in virtiofs. WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0 Modules linked in: CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7 Call Trace: <TASK> dax_iomap_rw+0xea/0x620 ? __this_cpu_preempt_check+0x13/0x20 fuse_dax_read_iter+0x47/0x80 fuse_file_read_iter+0xae/0xd0 new_sync_read+0xfe/0x180 ? 0xffffffff81000000 vfs_read+0x14d/0x1a0 ksys_read+0x6d/0xf0 __x64_sys_read+0x1a/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The tail command will call read() with a count of 0. In this case, iomap_iter() will report this WARNING, and always return 1 which casuing the infinite loop in dax_iomap_rw(). Fixing by checking count whether is 0 in dax_iomap_rw(). | ["https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3","https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0","https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744","https://git.kernel.org/stable/c/17d9c15c9b9e7fb285f7ac5367dfb5f00ff575e3","https://git.kernel.org/stable/c/60644dffac87b1bb47bdb393aa29d5f2ffcf41a0","https://git.kernel.org/stable/c/929ef155e1da41c06f4d8ca86ae12b851a83a744"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26763 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when using authenticated encryption It was said that authenticated encryption could produce invalid tag when the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same time. [1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/ | ["https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa","https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529","https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90","https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e","https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7","https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75","https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857","https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6","https://git.kernel.org/stable/c/0dccbb93538fe89a86c6de31d4b1c8c560848eaa","https://git.kernel.org/stable/c/1a4371db68a31076afbe56ecce34fbbe6c80c529","https://git.kernel.org/stable/c/3c652f6fa1e1f9f02c3fbf359d260ad153ec5f90","https://git.kernel.org/stable/c/43a202bd552976497474ae144942e32cc5f34d7e","https://git.kernel.org/stable/c/50c70240097ce41fe6bce6478b80478281e4d0f7","https://git.kernel.org/stable/c/64ba01a365980755732972523600a961c4266b75","https://git.kernel.org/stable/c/d9e3763a505e50ba3bd22846f2a8db99429fb857","https://git.kernel.org/stable/c/e08c2a8d27e989f0f5b0888792643027d7e691e6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23003 | Medium | fixed |
|
In the Linux kernel before 5.16, tools/perf/util/expr.c lacks a check for the hashmap__new return value. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16","https://github.com/torvalds/linux/commit/0a515a06c5ebfa46fee3ac519e418f801e718da4","https://security.netapp.com/advisory/ntap-20230331-0003/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16","https://github.com/torvalds/linux/commit/0a515a06c5ebfa46fee3ac519e418f801e718da4","https://security.netapp.com/advisory/ntap-20230331-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52467 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. | ["https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c","https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1","https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001","https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973","https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875","https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b","https://git.kernel.org/stable/c/3ef1130deee98997275904d9bfc37af75e1e906c","https://git.kernel.org/stable/c/41673c66b3d0c09915698fec5c13b24336f18dd1","https://git.kernel.org/stable/c/527e8c5f3d00299822612c495d5adf1f8f43c001","https://git.kernel.org/stable/c/7f2c410ac470959b88e03dadd94b7a0b71df7973","https://git.kernel.org/stable/c/927626a2073887ee30ba00633260d4d203f8e875","https://git.kernel.org/stable/c/c3e3a2144bf50877551138ffce9f7aa6ddfe385b","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1198 | Medium | fixed |
|
A use-after-free vulnerabilitity was discovered in drivers/net/hamradio/6pack.c of linux that allows an attacker to crash linux kernel by simulating ax25 device using 6pack driver from user space. | ["https://access.redhat.com/security/cve/CVE-2022-1198","https://bugzilla.redhat.com/show_bug.cgi?id=2070689","https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739","https://www.openwall.com/lists/oss-security/2022/04/02/3","https://access.redhat.com/security/cve/CVE-2022-1198","https://bugzilla.redhat.com/show_bug.cgi?id=2070689","https://github.com/torvalds/linux/commit/efe4186e6a1b54bf38b9e05450d43b0da1fd7739","https://www.openwall.com/lists/oss-security/2022/04/02/3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26811 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate payload size in ipc response If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc response to ksmbd kernel server. ksmbd should validate payload size of ipc response from ksmbd.mountd to avoid memory overrun or slab-out-of-bounds. This patch validate 3 ipc response that has payload. | ["https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd","https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896","https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300","https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c","https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac","https://git.kernel.org/stable/c/51a6c2af9d20203ddeeaf73314ba8854b38d01bd","https://git.kernel.org/stable/c/76af689a45aa44714b46d1a7de4ffdf851ded896","https://git.kernel.org/stable/c/88b7f1143b15b29cccb8392b4f38e75b7bb3e300","https://git.kernel.org/stable/c/a637fabac554270a851033f5ab402ecb90bc479c","https://git.kernel.org/stable/c/a677ebd8ca2f2632ccdecbad7b87641274e15aac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4135 | Medium | fixed |
|
A memory leak vulnerability was found in the Linux kernel's eBPF for the Simulated networking device driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called. A local user could use this flaw to get unauthorized access to some data. | ["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=481221775d53","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=481221775d53"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-23851 | Medium | N/A | copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl. | ["https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://www.spinics.net/lists/dm-devel/msg56574.html","https://www.spinics.net/lists/dm-devel/msg56694.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://www.spinics.net/lists/dm-devel/msg56574.html","https://www.spinics.net/lists/dm-devel/msg56694.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4218 | Medium | N/A | A flaw was found in the Linux kernel’s implementation of reading the SVC RDMA counters. Reading the counter sysctl panics the system. This flaw allows a local attacker with local access to cause a denial of service while the system reboots. The issue is specific to CentOS/RHEL. | ["https://access.redhat.com/security/cve/CVE-2021-4218","https://bugs.centos.org/view.php?id=18395","https://bugzilla.redhat.com/show_bug.cgi?id=2048359","https://access.redhat.com/security/cve/CVE-2021-4218","https://bugs.centos.org/view.php?id=18395","https://bugzilla.redhat.com/show_bug.cgi?id=2048359"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52499 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/47x: Fix 47x syscall return crash Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system: kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xb7ee2000 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K FSP-2 Modules linked in: CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1 Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP: b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2) MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return. However the branch back to label 1b doesn't return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi. The breakage was introduced by commit 6f76a01173cc ("powerpc/syscall: implement system call entry/exit logic in C for PPC32") which inadvertently removed the "1" label and reused it elsewhere. Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles. | ["https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820","https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746","https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3","https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14","https://git.kernel.org/stable/c/29017ab1a539101d9c7bec63cc13a019f97b2820","https://git.kernel.org/stable/c/70f6756ad96dd70177dddcfac2fe4bd4bb320746","https://git.kernel.org/stable/c/8ac2689502f986a46f4221e239d4ff2897f1ccb3","https://git.kernel.org/stable/c/f0eee815babed70a749d2496a7678be5b45b4c14"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52506 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set all reserved memblocks on Node#0 at initialization After commit 61167ad5fecdea ("mm: pass nid to reserve_bootmem_region()") we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733 [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90 [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0 [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000 [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800 [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20 [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000 [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000 [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000 [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0) [ 0.000000] BADV: 0000000000002b82 [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00 [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780 [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748 [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970 [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000 [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000 [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918 [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000 [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c [ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350 [ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc [ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4 [ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc [ 0.000000] [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd The reason is early memblock_reserve() in memblock_init() set node id to MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain reserve_bootmem_region() -> init_reserved_page(). After memblock_init(), those late calls of memblock_reserve() operate on subregions of memblock .memory regions. As a result, these reserved regions will be set to the correct node at the first iteration of memmap_init_reserved_pages(). So set all reserved memblocks on Node#0 at initialization can avoid this panic. | ["https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab","https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7","https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737","https://git.kernel.org/stable/c/19878758accf6b2788091a771d9f9fee7bab11ab","https://git.kernel.org/stable/c/b795fb9f5861ee256070d59e33130980a01fadd7","https://git.kernel.org/stable/c/f105e893a8edd48bdf4bef9fef845a9ff402f737"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26648 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix variable deferencing before NULL check in edp_setup_replay() In edp_setup_replay(), 'struct dc *dc' & 'struct dmub_replay *replay' was dereferenced before the pointer 'link' & 'replay' NULL check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:947 edp_setup_replay() warn: variable dereferenced before check 'link' (see line 933) | ["https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935","https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c","https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7","https://git.kernel.org/stable/c/22ae604aea14756954e1c00ae653e34d2afd2935","https://git.kernel.org/stable/c/7073934f5d73f8b53308963cee36f0d389ea857c","https://git.kernel.org/stable/c/c02d257c654191ecda1dc1af6875d527e85310e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-40768 | Medium | N/A | drivers/scsi/stex.c in the Linux kernel through 5.19.9 allows local users to obtain sensitive information from kernel memory because stex_queuecommand_lck lacks a memset for the PASSTHRU_CMD case. | ["http://www.openwall.com/lists/oss-security/2022/09/19/1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/","https://www.openwall.com/lists/oss-security/2022/09/09/1","http://www.openwall.com/lists/oss-security/2022/09/19/1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6022f210461fef67e6e676fd8544ca02d1bcfa7a","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/scsi/stex.c","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GGHENNMLCWIQV2LLA56BJNFIUZ7WB4IY/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/S2KTU5LFZNQS7YNGE56MT46VHMXL3DD2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/VNN3VFQPECS6D4PS6ZWD7AFXTOSJDSSR/","https://lore.kernel.org/all/20220908145154.2284098-1-gregkh%40linuxfoundation.org/","https://www.openwall.com/lists/oss-security/2022/09/09/1"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3078 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. There is a lack of check after calling vzalloc() and lack of free after allocation in drivers/media/test-drivers/vidtv/vidtv_s302m.c. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e6a21a14106d9718aa4f8e115b1e474888eeba44","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=e6a21a14106d9718aa4f8e115b1e474888eeba44"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3220 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 6.1-rc8. dpu_crtc_atomic_check in drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c lacks check of the return value of kzalloc() and will cause the NULL Pointer Dereference. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93340e10b9c5fc86730d149636e0aa8b47bb5a34","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=93340e10b9c5fc86730d149636e0aa8b47bb5a34"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52596 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix out of bounds access for empty sysctl registers When registering tables to the sysctl subsystem there is a check to see if header is a permanently empty directory (used for mounts). This check evaluates the first element of the ctl_table. This results in an out of bounds evaluation when registering empty directories. The function register_sysctl_mount_point now passes a ctl_table of size 1 instead of size 0. It now relies solely on the type to identify a permanently empty register. Make sure that the ctl_table has at least one element before testing for permanent emptiness. | ["https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede","https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489","https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843","https://git.kernel.org/stable/c/15893975e9e382f8294ea8d926f08dc2d8d39ede","https://git.kernel.org/stable/c/2ae7081bc10123b187e36a4f3a8e53768de31489","https://git.kernel.org/stable/c/315552310c7de92baea4e570967066569937a843"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26715 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. | ["https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182","https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751","https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316","https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7","https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b","https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182","https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751","https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8d44c316","https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7","https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1079 | Medium | fixed |
|
A flaw was found in the Linux kernel. A use-after-free may be triggered in asus_kbd_backlight_set when plugging/disconnecting in a malicious USB device, which advertises itself as an Asus device. Similarly to the previous known CVE-2023-25012, but in asus devices, the work_struct may be scheduled by the LED controller while the device is disconnecting, triggering a use-after-free on the struct asus_kbd_leds *led structure. A malicious USB device may exploit the issue to cause memory corruption with controlled data. | ["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52497 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don't have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with "rep movsb". Let's strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. | ["https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847","https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de","https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184","https://git.kernel.org/stable/c/9ff2d260b25df6fe1341a79113d88fecf6bd553e","https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379","https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e","https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae","https://git.kernel.org/stable/c/33bf23c9940dbd3a22aad7f0cda4c84ed5701847","https://git.kernel.org/stable/c/3c12466b6b7bf1e56f9b32c366a3d83d87afb4de","https://git.kernel.org/stable/c/77cbc04a1a8610e303a0e0d74f2676667876a184","https://git.kernel.org/stable/c/a0180e940cf1aefa7d516e20b259ad34f7a8b379","https://git.kernel.org/stable/c/bffc4cc334c5bb31ded54bc3cfd651735a3cb79e","https://git.kernel.org/stable/c/f36d200a80a3ca025532ed60dd1ac21b620e14ae","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35823 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in saa7134_finidev in drivers/media/pci/saa7134/saa7134-core.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30cf57da176cca80f11df0d9b7f71581fe601389","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318085023.832510-1-zyytlz.wz%40163.com/t/","https://security.netapp.com/advisory/ntap-20230803-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1247 | High | N/A | An issue found in linux-kernel that leads to a race condition in rose_connect(). The rose driver uses rose_neigh->use to represent how many objects are using the rose_neigh. When a user wants to delete a rose_route via rose_ioctl(), the rose driver calls rose_del_node() and removes neighbours only if their “count” and “use” are zero. | ["https://access.redhat.com/security/cve/CVE-2022-1247","https://bugzilla.redhat.com/show_bug.cgi?id=2066799","https://access.redhat.com/security/cve/CVE-2022-1247","https://bugzilla.redhat.com/show_bug.cgi?id=2066799"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46695 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. | ["https://git.kernel.org/stable/c/2dbc4b7bac60b02cc6e70d05bf6a7dfd551f9dda","https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57","https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7","https://git.kernel.org/stable/c/eebec98791d0137e455cc006411bb92a54250924","https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96","https://git.kernel.org/stable/c/fe0cd53791119f6287b6532af8ce41576d664930"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-36402 | Medium | N/A | An integer overflow vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=2072","https://bugzilla.openanolis.cn/show_bug.cgi?id=2072"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-38096 | Medium | N/A | A NULL pointer dereference vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in GPU component of Linux kernel with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=2073","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://bugzilla.openanolis.cn/show_bug.cgi?id=2073","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-38457 | Medium | fixed |
|
A use-after-free(UAF) vulnerability was found in function 'vmw_cmd_res_check' in drivers/gpu/vmxgfx/vmxgfx_execbuf.c in Linux kernel's vmwgfx driver with device file '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS). | ["https://bugzilla.openanolis.cn/show_bug.cgi?id=2074","https://bugzilla.openanolis.cn/show_bug.cgi?id=2074"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3564 | Medium | N/A | A flaw double-free memory corruption in the Linux kernel HCI device initialization subsystem was found in the way user attach malicious HCI TTY Bluetooth device. A local user could use this flaw to crash the system. This flaw affects all the Linux kernel versions starting from 3.13. | ["http://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/06/01/2","https://bugzilla.redhat.com/show_bug.cgi?id=1964139","https://lists.debian.org/debian-lts-announce/2021/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2021/06/msg00020.html","https://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/05/25/1","http://www.openwall.com/lists/oss-security/2021/06/01/2","https://bugzilla.redhat.com/show_bug.cgi?id=1964139","https://lists.debian.org/debian-lts-announce/2021/06/msg00019.html","https://lists.debian.org/debian-lts-announce/2021/06/msg00020.html","https://www.openwall.com/lists/oss-security/2021/05/25/1"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2898 | Medium | N/A | There is a null-pointer-dereference flaw found in f2fs_write_end_io in fs/f2fs/data.c in the Linux kernel. This flaw allows a local privileged user to cause a denial of service problem. | ["https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-f2fs-devel/20230522124203.3838360-1-chao%40kernel.org/","https://security.netapp.com/advisory/ntap-20230929-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/linux-f2fs-devel/20230522124203.3838360-1-chao%40kernel.org/","https://security.netapp.com/advisory/ntap-20230929-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-40307 | Medium | N/A | An issue was discovered in the Linux kernel through 5.19.8. drivers/firmware/efi/capsule-loader.c has a race condition with a resultant use-after-free. | ["https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257","https://github.com/torvalds/linux/commit/9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41848 | Medium | N/A | drivers/char/pcmcia/synclink_cs.c in the Linux kernel through 5.19.12 has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling ioctl, aka a race condition between mgslpc_ioctl and mgslpc_detach. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c","https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/drivers/char/pcmcia/synclink_cs.c","https://lore.kernel.org/lkml/20220919040251.GA302541%40ubuntu/T/#rc85e751f467b3e6f9ccef92cfa7fb8a6cc50c270"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3636 | High | N/A | A vulnerability, which was classified as critical, was found in Linux Kernel. This affects the function __mtk_ppe_check_skb of the file drivers/net/ethernet/mediatek/mtk_ppe.c of the component Ethernet Handler. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211935. | ["https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=17a5f6a78dc7b8db385de346092d7d9f9dc24df6","https://vuldb.com/?id.211935","https://www.debian.org/security/2023/dsa-5333","https://git.kernel.org/pub/scm/linux/kernel/git/pabeni/net-next.git/commit/?id=17a5f6a78dc7b8db385de346092d7d9f9dc24df6","https://vuldb.com/?id.211935","https://www.debian.org/security/2023/dsa-5333"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52510 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). | ["https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66","https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add","https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f","https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e","https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc","https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640","https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d","https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258","https://git.kernel.org/stable/c/217efe32a45249eb07dcd7197e8403de98345e66","https://git.kernel.org/stable/c/28b68cba378e3e50a4082b65f262bc4f2c7c2add","https://git.kernel.org/stable/c/55e06850c7894f00d41b767c5f5665459f83f58f","https://git.kernel.org/stable/c/84c6aa0ae5c4dc121f9996bb8fed46c80909d80e","https://git.kernel.org/stable/c/85c2857ef90041f567ce98722c1c342c4d31f4bc","https://git.kernel.org/stable/c/becf5c147198f4345243c5df0c4f035415491640","https://git.kernel.org/stable/c/cdb46be93c1f7bbf2c4649e9fc5fb147cfb5245d","https://git.kernel.org/stable/c/f990874b1c98fe8e57ee9385669f501822979258"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26895 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind ================================================================== BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/ | ["https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9","https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447","https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208","https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb","https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f","https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c","https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1","https://git.kernel.org/stable/c/24228dcf1d30c2231caa332be7d3090ac59fbfe9","https://git.kernel.org/stable/c/3da9d32b7f4a1a9f7e4bb15bb82f2b2dd6719447","https://git.kernel.org/stable/c/5956f4203b6cdd0755bbdd21b45f3933c7026208","https://git.kernel.org/stable/c/73a2aa0aef86c2c07be5a2f42c9e6047e1a2f7bb","https://git.kernel.org/stable/c/a9545af2a533739ffb64d6c9a6fec6f13e2b505f","https://git.kernel.org/stable/c/cb5942b77c05d54310a0420cac12935e9b6aa21c","https://git.kernel.org/stable/c/fe20e3d56bc911408fc3c27a17c59e9d7885f7d1","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26885 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix DEVMAP_HASH overflow check on 32-bit arches The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. | ["https://git.kernel.org/stable/c/1f5e352b9088211fa5eb4e1639cd365f4f7d2f65","https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c","https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691","https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3","https://git.kernel.org/stable/c/4b81a9f92b3676cb74b907a7a209b3d15bd9a7f9","https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3","https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c","https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737","https://git.kernel.org/stable/c/22079b3a423382335f47d9ed32114e6c9fe88d7c","https://git.kernel.org/stable/c/225da02acdc97af01b6bc6ce1a3e5362bf01d3fb","https://git.kernel.org/stable/c/250051acc21f9d4c5c595e4fcb55986ea08c4691","https://git.kernel.org/stable/c/281d464a34f540de166cee74b723e97ac2515ec3","https://git.kernel.org/stable/c/c826502bed93970f2fd488918a7b8d5f1d30e2e3","https://git.kernel.org/stable/c/e89386f62ce9a9ab9a94835a9890883c23d9d52c","https://git.kernel.org/stable/c/edf7990baa48de5097daa9ac02e06cb4c798a737","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3090 | High | fixed |
|
A heap out-of-bounds write vulnerability in the Linux Kernel ipvlan network driver can be exploited to achieve local privilege escalation. The out-of-bounds write is caused by missing skb->cb initialization in the ipvlan network driver. The vulnerability is reachable if CONFIG_IPVLAN is enabled. We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e. | ["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e","https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbed5247439a966b645b34eb0a2e037836ea8e","https://kernel.dance/90cbed5247439a966b645b34eb0a2e037836ea8e","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230731-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49053 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: target: tcmu: Fix possible page UAF tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release(). | ["https://git.kernel.org/stable/c/a6968f7a367f128d120447360734344d5a3d5336","https://git.kernel.org/stable/c/a9564d84ed9f6ee71017d062d0d2182154294a4b","https://git.kernel.org/stable/c/aec36b98a1bbaa84bfd8299a306e4c12314af626","https://git.kernel.org/stable/c/b7f3b5d70c834f49f7d87a2f2ed1c6284d9a0322","https://git.kernel.org/stable/c/d7c5d79e50be6e06b669141e3db1f977a0dd4e8e","https://git.kernel.org/stable/c/e3e0e067d5b34e4a68e3cc55f8eebc413f56f8ed","https://git.kernel.org/stable/c/fb7a5115422fbd6a4d505e8844f1ef5529f10489"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26913 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dcn35 8k30 Underflow/Corruption Issue [why] odm calculation is missing for pipe split policy determination and cause Underflow/Corruption issue. [how] Add the odm calculation. | ["https://git.kernel.org/stable/c/cdbe0be8874c63bca85b8c38e5b1eecbdd18df31","https://git.kernel.org/stable/c/faf51b201bc42adf500945732abb6220c707d6f3","https://git.kernel.org/stable/c/cdbe0be8874c63bca85b8c38e5b1eecbdd18df31","https://git.kernel.org/stable/c/faf51b201bc42adf500945732abb6220c707d6f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56708 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: EDAC/igen6: Avoid segmentation fault on module unload The segmentation fault happens because: During modprobe: 1. In igen6_probe(), igen6_pvt will be allocated with kzalloc() 2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc] During rmmod: 1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info) 2. In igen6_remove(), it will kfree(igen6_pvt); Fix this issue by setting mci->pvt_info to NULL to avoid the double kfree. | ["https://git.kernel.org/stable/c/029ac07bb92d2f7502d47a4916f197a8445d83bf","https://git.kernel.org/stable/c/2a80e710bbc088a2511c159ee4d910456c5f0832","https://git.kernel.org/stable/c/830cabb61113d92a425dd3038ccedbdfb3c8d079","https://git.kernel.org/stable/c/db60326f2c47b079e36785ace621eb3002db2088","https://git.kernel.org/stable/c/e5c7052664b61f9e2f896702d20552707d0ef60a","https://git.kernel.org/stable/c/fefaae90398d38a1100ccd73b46ab55ff4610fba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56626 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix Out-of-Bounds Write in ksmbd_vfs_stream_write An offset from client could be a negative value, It could allows to write data outside the bounds of the allocated buffer. Note that this issue is coming when setting 'vfs objects = streams_xattr parameter' in ksmbd.conf. | ["https://git.kernel.org/stable/c/164d3597d26d9acff5d5b8bc3208bdcca942dd6a","https://git.kernel.org/stable/c/1aea5c9470be2c7129704fb1b9562b1e3e0576f8","https://git.kernel.org/stable/c/313dab082289e460391c82d855430ec8a28ddf81","https://git.kernel.org/stable/c/8cd7490fc0f268883e86e840cda5311257af69ca","https://git.kernel.org/stable/c/c5797f195c67132d061d29c57a7c6d30530686f0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26884 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on 32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. | ["https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5","https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d","https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6","https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1","https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868","https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace","https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016","https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93","https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e","https://git.kernel.org/stable/c/33ec04cadb77605b71d9298311919303d390c4d5","https://git.kernel.org/stable/c/3b08cfc65f07b1132c1979d73f014ae6e04de55d","https://git.kernel.org/stable/c/64f00b4df0597590b199b62a37a165473bf658a6","https://git.kernel.org/stable/c/6787d916c2cf9850c97a0a3f73e08c43e7d973b1","https://git.kernel.org/stable/c/8435f0961bf3dc65e204094349bd9aeaac1f8868","https://git.kernel.org/stable/c/92c81fbb3ed2e0dfc33a4183a67135e1ab566ace","https://git.kernel.org/stable/c/a6fa75b5096c0f9826a4fabe22d907b0a5bb1016","https://git.kernel.org/stable/c/a83fdaeaea3677b83a53f72ace2d73a19bcd6d93","https://git.kernel.org/stable/c/d817f0d34d927f2deb17dadbfe212c9a6a32ac3e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52601 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in dbAdjTree Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ | ["https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317","https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c","https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555","https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e","https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603","https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b","https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e","https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73","https://git.kernel.org/stable/c/2037cb9d95f1741885f7daf50e8a028c4ade5317","https://git.kernel.org/stable/c/2e16a1389b5a7983b45cb2aa20b0e3f0ee364d6c","https://git.kernel.org/stable/c/3d3898b4d72c677d47fe3cb554449f2df5c12555","https://git.kernel.org/stable/c/3f8217c323fd6ecd6829a0c3ae7ac3f14eac368e","https://git.kernel.org/stable/c/70780914cb57e2ba711e0ac1b677aaaa75103603","https://git.kernel.org/stable/c/74ecdda68242b174920fe7c6133a856fb7d8559b","https://git.kernel.org/stable/c/8393c80cce45f40c1256d72e21ad351b3650c57e","https://git.kernel.org/stable/c/fc67a2e18f4c4e3f07e9f9ae463da24530470e73","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52572 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: Fix UAF in cifs_demultiplex_thread() There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The UAF is because: mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------------------------- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback 1. After send request to server, wait the response until mid->mid_state != SUBMITTED; 2. Receive response from server, and set it to mid; 3. Set the mid state to RECEIVED; 4. Kill the process, the mid state already RECEIVED, get 0; 5. Handle and release the negotiate response; 6. UAF. It can be easily reproduce with add some delay in [3] - [6]. Only sync call has the problem since async call's callback is executed in cifsd process. Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely. | ["https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a","https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3","https://git.kernel.org/stable/c/99960d282fba6634fa758df4124cb73ef8a77d8a","https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f","https://git.kernel.org/stable/c/ed3b36f351d97dacb62cd0f399e8cf79f73bd30a","https://git.kernel.org/stable/c/76569e3819e0bb59fc19b1b8688b017e627c268a","https://git.kernel.org/stable/c/908b3b5e97d25e879de3d1f172a255665491c2c3","https://git.kernel.org/stable/c/d527f51331cace562393a8038d870b3e9916686f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6040 | High | fixed |
|
An out-of-bounds access vulnerability involving netfilter was reported and fixed as: f1082dd31fe4 (netfilter: nf_tables: Reject tables of unsupported family); While creating a new netfilter table, lack of a safeguard against invalid nf_tables family (pf) values within `nf_tables_newtable` function enables an attacker to achieve out-of-bounds access. | ["http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2024/01/12/1","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.openwall.com/lists/oss-security/2024/01/12/1","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","http://www.openwall.com/lists/oss-security/2024/01/12/1","https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6040","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.openwall.com/lists/oss-security/2024/01/12/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48425 | High | fixed |
|
In the Linux kernel through 6.2.7, fs/ntfs3/inode.c has an invalid kfree because it does not validate MFT flags before replaying logs. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://security.netapp.com/advisory/ntap-20230413-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd","https://security.netapp.com/advisory/ntap-20230413-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26704 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. | ["https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1","https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f","https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4","https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6","https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1","https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1","https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71","https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537","https://git.kernel.org/stable/c/185eab30486ba3e7bf8b9c2e049c79a06ffd2bc1","https://git.kernel.org/stable/c/2883940b19c38d5884c8626483811acf4d7e148f","https://git.kernel.org/stable/c/55583e899a5357308274601364741a83e78d6ac4","https://git.kernel.org/stable/c/559ddacb90da1d8786dd8ec4fd76bbfa404eaef6","https://git.kernel.org/stable/c/afba9d11320dad5ce222ac8964caf64b7b4bedb1","https://git.kernel.org/stable/c/afbcad9ae7d6d11608399188f03a837451b6b3a1","https://git.kernel.org/stable/c/b4fbb89d722cbb16beaaea234b7230faaaf68c71","https://git.kernel.org/stable/c/d033a555d9a1cf53dbf3301af7199cc4a4c8f537","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52451 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/memhp: Fix access beyond end of drmem array dlpar_memory_remove_by_index() may access beyond the bounds of the drmem lmb array when the LMB lookup fails to match an entry with the given DRC index. When the search fails, the cursor is left pointing to &drmem_info->lmbs[drmem_info->n_lmbs], which is one element past the last valid entry in the array. The debug message at the end of the function then dereferences this pointer: pr_debug("Failed to hot-remove memory at %llx\n", lmb->base_addr); This was found by inspection and confirmed with KASAN: pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234 ================================================================== BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658 Read of size 8 at addr c000000364e97fd0 by task bash/949 dump_stack_lvl+0xa4/0xfc (unreliable) print_report+0x214/0x63c kasan_report+0x140/0x2e0 __asan_load8+0xa8/0xe0 dlpar_memory+0x298/0x1658 handle_dlpar_errorlog+0x130/0x1d0 dlpar_store+0x18c/0x3e0 kobj_attr_store+0x68/0xa0 sysfs_kf_write+0xc4/0x110 kernfs_fop_write_iter+0x26c/0x390 vfs_write+0x2d4/0x4e0 ksys_write+0xac/0x1a0 system_call_exception+0x268/0x530 system_call_vectored_common+0x15c/0x2ec Allocated by task 1: kasan_save_stack+0x48/0x80 kasan_set_track+0x34/0x50 kasan_save_alloc_info+0x34/0x50 __kasan_kmalloc+0xd0/0x120 __kmalloc+0x8c/0x320 kmalloc_array.constprop.0+0x48/0x5c drmem_init+0x2a0/0x41c do_one_initcall+0xe0/0x5c0 kernel_init_freeable+0x4ec/0x5a0 kernel_init+0x30/0x1e0 ret_from_kernel_user_thread+0x14/0x1c The buggy address belongs to the object at c000000364e80000 which belongs to the cache kmalloc-128k of size 131072 The buggy address is located 0 bytes to the right of allocated 98256-byte region [c000000364e80000, c000000364e97fd0) ================================================================== pseries-hotplug-mem: Failed to hot-remove memory at 0 Log failed lookups with a separate message and dereference the cursor only when it points to a valid entry. | ["https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0","https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc","https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d","https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7","https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e","https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c","https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5","https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e","https://git.kernel.org/stable/c/026fd977dc50ff4a5e09bfb0603557f104d3f3a0","https://git.kernel.org/stable/c/708a4b59baad96c4718dc0bd3a3427d3ab22fedc","https://git.kernel.org/stable/c/999a27b3ce9a69d54ccd5db000ec3a447bc43e6d","https://git.kernel.org/stable/c/9b5f03500bc5b083c0df696d7dd169d7ef3dd0c7","https://git.kernel.org/stable/c/b582aa1f66411d4adcc1aa55b8c575683fb4687e","https://git.kernel.org/stable/c/bb79613a9a704469ddb8d6c6029d532a5cea384c","https://git.kernel.org/stable/c/bd68ffce69f6cf8ddd3a3c32549d1d2275e49fc5","https://git.kernel.org/stable/c/df16afba2378d985359812c865a15c05c70a967e","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52469 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-free bug. | ["https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743","https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02","https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706","https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3","https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e","https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63","https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3","https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a","https://git.kernel.org/stable/c/28dd788382c43b330480f57cd34cde0840896743","https://git.kernel.org/stable/c/3426f059eacc33ecc676b0d66539297e1cfafd02","https://git.kernel.org/stable/c/35fa2394d26e919f63600ce631e6aefc95ec2706","https://git.kernel.org/stable/c/520e213a0b97b64735a13950e9371e0a5d7a5dc3","https://git.kernel.org/stable/c/8a27d9d9fc9b5564b8904c3a77a7dea482bfa34e","https://git.kernel.org/stable/c/8b55b06e737feb2a645b0293ea27e38418876d63","https://git.kernel.org/stable/c/95084632a65d5c0d682a83b55935560bdcd2a1e3","https://git.kernel.org/stable/c/b6dcba02ee178282e0d28684d241e0b8462dea6a","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26625 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: llc: call sock_orphan() at release time syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket. In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling proto_ops::release()") Eric Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK> Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin ---truncated--- | ["https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812","https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f","https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b","https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4","https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee","https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c","https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7","https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a","https://git.kernel.org/stable/c/3151051b787f7cd7e3329ea0016eb9113c248812","https://git.kernel.org/stable/c/64babb17e8150771c58575d8f93a35c5296b499f","https://git.kernel.org/stable/c/6b950c712a9a05cdda4aea7fcb2848766576c11b","https://git.kernel.org/stable/c/8e51f084b5716653f19e291ed5f026791d4b3ed4","https://git.kernel.org/stable/c/9c333d9891f34cea8af1b229dc754552304c8eee","https://git.kernel.org/stable/c/aa2b2eb3934859904c287bf5434647ba72e14c1c","https://git.kernel.org/stable/c/d0b5b1f12429df3cd9751ab8b2f53729b77733b7","https://git.kernel.org/stable/c/dbc1b89981f9c5360277071d33d7f04a43ffda4a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52491 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run In mtk_jpeg_probe, &jpeg->job_timeout_work is bound with mtk_jpeg_job_timeout_work. In mtk_jpeg_dec_device_run, if error happens in mtk_jpeg_set_dec_dst, it will finally start the worker while mark the job as finished by invoking v4l2_m2m_job_finish. There are two methods to trigger the bug. If we remove the module, it which will call mtk_jpeg_remove to make cleanup. The possible sequence is as follows, which will cause a use-after-free bug. CPU0 CPU1 mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_work mtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //use If we close the file descriptor, which will call mtk_jpeg_release, it will have a similar sequence. Fix this bug by starting timeout worker only if started jpegdec worker successfully. Then v4l2_m2m_job_finish will only be called in either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run. | ["https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590","https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e","https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9","https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c","https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7","https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6","https://git.kernel.org/stable/c/1b1036c60a37a30caf6759a90fe5ecd06ec35590","https://git.kernel.org/stable/c/206c857dd17d4d026de85866f1b5f0969f2a109e","https://git.kernel.org/stable/c/43872f44eee6c6781fea1348b38885d8e78face9","https://git.kernel.org/stable/c/6e2f37022f0fc0893da4d85a0500c9d547fffd4c","https://git.kernel.org/stable/c/8254d54d00eb6cdb8367399c7f912eb8d354ecd7","https://git.kernel.org/stable/c/9fec4db7fff54d9b0306a332bab31eac47eeb5f6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50044 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491 | ["https://git.kernel.org/stable/c/08d1914293dae38350b8088980e59fbc699a72fe","https://git.kernel.org/stable/c/38b2d5a57d125e1c17661b8308c0240c4a43b534","https://git.kernel.org/stable/c/496b2ab0fd10f205e08909a125485fdc98843dbe","https://git.kernel.org/stable/c/4cb9807c9b53bf1e5560420d26f319f528b50268","https://git.kernel.org/stable/c/869c6ee62ab8f01bf2419e45326642be5c9b670a","https://git.kernel.org/stable/c/b77b3fb12fd483cae7c28648903b1d8a6b275f01","https://git.kernel.org/stable/c/ced98072d3511b232ae1d3347945f35f30c0e303","https://git.kernel.org/stable/c/ef44274dae9b0a90d1a97ce8b242a3b8243a7745"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-30772 | Medium | fixed |
|
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/power/supply/da9150-charger.c if a physically proximate attacker unplugs a device. | ["https://bugzilla.suse.com/show_bug.cgi?id=1210329","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.suse.com/show_bug.cgi?id=1210329","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=06615d11cc78162dfd5116efb71f29eb29502d37","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56745 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reset_method_store() memory leak In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces: while ((name = strsep(&options, " ")) != NULL) { If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup(). Fix by using a separate tmp_options to iterate with strsep() so options is preserved. | ["https://git.kernel.org/stable/c/2985b1844f3f3447f2d938eff1ef6762592065a5","https://git.kernel.org/stable/c/403efb4457c0c8f8f51e904cc57d39193780c6bd","https://git.kernel.org/stable/c/543d0eb40e45c6a51f1bff02f417b602e54472d5","https://git.kernel.org/stable/c/8e098baf6bc3f3a6aefc383509aba07e202f7ee0","https://git.kernel.org/stable/c/931d07ccffcc3614f20aaf602b31e89754e21c59","https://git.kernel.org/stable/c/fe6fae61f3b993160aef5fe2b7141a83872c144f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49035 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: s5p_cec: limit msg.len to CEC_MAX_MSG_SIZE I expect that the hardware will have limited this to 16, but just in case it hasn't, check for this corner case. | ["https://git.kernel.org/stable/c/1609231f86760c1f6a429de7913dd795b9faa08c","https://git.kernel.org/stable/c/2654e785bd4aa2439cdffbe7dc1ea30a0eddbfe4","https://git.kernel.org/stable/c/4a449430ecfb199b99ba58af63c467eb53500b39","https://git.kernel.org/stable/c/7ccb40f26cbefa1c6dfd3418bea54c9518cdbd8a","https://git.kernel.org/stable/c/93f65ce036863893c164ca410938e0968964b26c","https://git.kernel.org/stable/c/a2728bf9b6c65e46468c763e3dab7e04839d4e11","https://git.kernel.org/stable/c/cbfa26936f318b16ccf9ca31b8e8b30c0dc087bd","https://git.kernel.org/stable/c/fc0f76dd5f116fa9291327024dda392f8b4e849c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48656 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get() We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check. | ["https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2","https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5","https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d","https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e","https://git.kernel.org/stable/c/a17df55bf6d536712da6902a83db82b82e67d5a2","https://git.kernel.org/stable/c/aa11dae059a439af82bae541b134f8f53ac177b5","https://git.kernel.org/stable/c/dd5a6c5a08752b613e83ad2cb5133e72a64b876d","https://git.kernel.org/stable/c/f9fdb0b86f087c2b7f6c6168dd0985a3c1eda87e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mISDN: Fix memory leak in dsp_pipeline_build() dsp_pipeline_build() allocates dup pointer by kstrdup(cfg), but then it updates dup variable by strsep(&dup, "|"). As a result when it calls kfree(dup), the dup variable contains NULL. Found by Linux Driver Verification project (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f","https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b","https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a269631092570aa285a24cb","https://git.kernel.org/stable/c/c6a502c2299941c8326d029cfc8a3bc8a4607ad5","https://git.kernel.org/stable/c/640445d6fc059d4514ffea79eb4196299e0e2d0f","https://git.kernel.org/stable/c/7777b1f795af1bb43867375d8a776080111aae1b","https://git.kernel.org/stable/c/a3d5fcc6cf2ecbba5a269631092570aa285a24cb","https://git.kernel.org/stable/c/c6a502c2299941c8326d029cfc8a3bc8a4607ad5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48865 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: fix kernel panic when enabling bearer When enabling a bearer on a node, a kernel panic is observed: [ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc] [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc] [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc] [ 4.525292] tipc_rcv+0x5da/0x730 [tipc] [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0 [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc] [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260 [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0 [ 4.531450] ? dev_gro_receive+0x4c2/0x680 [ 4.532512] napi_complete_done+0x6f/0x180 [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net] ... The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread: thread 1 | thread 2 -------- | -------- | tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } | Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. This causes kernel panic. This commit fixes it by allocating the monitoring data before enabling the bearer to receive messages. | ["https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5","https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3","https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94","https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71","https://git.kernel.org/stable/c/2de76d37d4a6dca9b96ea51da24d4290e6cfa1a5","https://git.kernel.org/stable/c/be4977b847f5d5cedb64d50eaaf2218c3a55a3a3","https://git.kernel.org/stable/c/f4f59fdbc748805b08c13dae14c01f0518c77c94","https://git.kernel.org/stable/c/f96dc3adb9a97b8f3dfdb88796483491a3006b71"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53187 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: io_uring: check for overflows in io_pin_pages WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace: <TASK> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183 io_rings_map io_uring/io_uring.c:2611 [inline] io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470 io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692 io_uring_setup io_uring/io_uring.c:3781 [inline] ... </TASK> io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow. | ["https://git.kernel.org/stable/c/0c0a4eae26ac78379d0c1db053de168a8febc6c9","https://git.kernel.org/stable/c/29eac3eca72d4c2a71122050c37cd7d8f73ac4f3","https://git.kernel.org/stable/c/aaa90844afd499c9142d0199dfda74439314c013"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56611 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM We currently assume that there is at least one VMA in a MM, which isn't true. So we might end up having find_vma() return NULL, to then de-reference NULL. So properly handle find_vma() returning NULL. This fixes the report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [akpm@linux-foundation.org: add unlikely()] | ["https://git.kernel.org/stable/c/091c1dd2d4df6edd1beebe0e5863d4034ade9572","https://git.kernel.org/stable/c/42d9fe2adf8613f9eea1f0c2619c9e2611eae0ea","https://git.kernel.org/stable/c/a13b2b9b0b0b04612c7d81e3b3dfb485c5f7abc3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56657 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Avoid WARN() for symlink errors Using WARN() for showing the error of symlink creations don't give more information than telling that something goes wrong, since the usual code path is a lregister callback from each control element creation. More badly, the use of WARN() rather confuses fuzzer as if it were serious issues. This patch downgrades the warning messages to use the normal dev_err() instead of WARN(). For making it clearer, add the function name to the prefix, too. | ["https://git.kernel.org/stable/c/36c0764474b637bbee498806485bed524cad486b","https://git.kernel.org/stable/c/b2e538a9827dd04ab5273bf4be8eb2edb84357b0","https://git.kernel.org/stable/c/d5a1ca7b59804d6779644001a878ed925a4688ca"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53224 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Move events notifier registration to be after device registration Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events. Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below. BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]--- | ["https://git.kernel.org/stable/c/542bd62b7a7f37182c9ef192c2bd25d118c144e4","https://git.kernel.org/stable/c/6b0acf6a94c31efa43fce4edc22413a3390f9c05","https://git.kernel.org/stable/c/921fcf2971a1e8d3b904ba2c2905b96f4ec3d4ad","https://git.kernel.org/stable/c/ede132a5cf559f3ab35a4c28bac4f4a6c20334d8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56557 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer The AD7923 was updated to support devices with 8 channels, but the size of tx_buf and ring_xfer was not increased accordingly, leading to a potential buffer overflow in ad7923_update_scan_mode(). | ["https://git.kernel.org/stable/c/00663d3e000c31d0d49ef86a809f5c107c2d09cd","https://git.kernel.org/stable/c/218ecc35949129171ca39bcc0d407c8dc4cd0bbc","https://git.kernel.org/stable/c/3a4187ec454e19903fd15f6e1825a4b84e59a4cd","https://git.kernel.org/stable/c/e5cac32721997cb8bcb208a29f4598b3faf46338"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53151 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: svcrdma: Address an integer overflow Dan Carpenter reports: > Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data > structure") from Jun 22, 2020 (linux-next), leads to the following > Smatch static checker warning: > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk() > warn: potential user controlled sizeof overflow 'segcount * 4 * 4' > > net/sunrpc/xprtrdma/svc_rdma_recvfrom.c > 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt) > 489 { > 490 u32 segcount; > 491 __be32 *p; > 492 > 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount)) > ^^^^^^^^ > > 494 return false; > 495 > 496 /* A bogus segcount causes this buffer overflow check to fail. */ > 497 p = xdr_inline_decode(&rctxt->rc_stream, > --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p)); > > > segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will > have an integer overflow and some those values will be accepted by > xdr_inline_decode(). | ["https://git.kernel.org/stable/c/21e1cf688fb0397788c8dd42e1e0b08d58ac5c7b","https://git.kernel.org/stable/c/3c63d8946e578663b868cb9912dac616ea68bfd0","https://git.kernel.org/stable/c/4cbc3ba6dc2f746497cade60bcbaa82ae3696689","https://git.kernel.org/stable/c/838dd342962cef4c320632a5af48d3c31f2f9877","https://git.kernel.org/stable/c/c1f8195bf68edd2cef0f18a4cead394075a54b5a","https://git.kernel.org/stable/c/e5c440c227ecdc721f2da0dd88b6358afd1031a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1195 | Medium | fixed |
|
A use-after-free flaw was found in reconn_set_ipaddr_from_hostname in fs/cifs/connect.c in the Linux kernel. The issue occurs when it forgets to set the free pointer server->hostname to NULL, leading to an invalid pointer request. | ["https://github.com/torvalds/linux/commit/153695d36ead0ccc4d0256953c751cabf673e621","https://github.com/torvalds/linux/commit/153695d36ead0ccc4d0256953c751cabf673e621"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53079 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases. | ["https://git.kernel.org/stable/c/afb1352d06b1b6b2cfd1f901c766a430c87078b3","https://git.kernel.org/stable/c/f8f931bba0f92052cf842b7e30917b1afcc77d5a","https://git.kernel.org/stable/c/fc4951c3e3358dd82ea508e893695b916c813f17"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3110 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. _rtw_init_xmit_priv in drivers/staging/r8188eu/core/rtw_xmit.c lacks check of the return value of rtw_alloc_hwxmits() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153055","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=f94b47c6bde624d6c07f43054087607c52054a95","https://bugzilla.redhat.com/show_bug.cgi?id=2153055","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=f94b47c6bde624d6c07f43054087607c52054a95"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26660 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN301 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn301_stream_encoder_create reported by Smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5 | ["https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054","https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2","https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738","https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d","https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a","https://git.kernel.org/stable/c/42442f74314d41ddc68227047036fa3e78940054","https://git.kernel.org/stable/c/58fca355ad37dcb5f785d9095db5f748b79c5dc2","https://git.kernel.org/stable/c/a938eab9586eea31cfd129a507f552efae14d738","https://git.kernel.org/stable/c/cd9bd10c59e3c1446680514fd3097c5b00d3712d","https://git.kernel.org/stable/c/efdd665ce1a1634b8c1dad5e7f6baaef3e131d0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52631 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix an NULL dereference bug The issue here is when this is called from ntfs_load_attr_list(). The "size" comes from le32_to_cpu(attr->res.data_size) so it can't overflow on a 64bit systems but on 32bit systems the "+ 1023" can overflow and the result is zero. This means that the kmalloc will succeed by returning the ZERO_SIZE_PTR and then the memcpy() will crash with an Oops on the next line. | ["https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2","https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b","https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c","https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6","https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7","https://git.kernel.org/stable/c/686820fe141ea0220fc6fdfc7e5694f915cf64b2","https://git.kernel.org/stable/c/ae4acad41b0f93f1c26cc0fc9135bb79d8282d0b","https://git.kernel.org/stable/c/b2dd7b953c25ffd5912dda17e980e7168bebcf6c","https://git.kernel.org/stable/c/ec1bedd797588fe38fc11cba26d77bb1d9b194c6","https://git.kernel.org/stable/c/fb7bcd1722bc9bc55160378f5f99c01198fd14a7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52641 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there. | ["https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc","https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd","https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c","https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a","https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b","https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc","https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd","https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c","https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a","https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49901 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-mq: Fix kmemleak in blk_mq_init_allocated_queue There is a kmemleak caused by modprobe null_blk.ko unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 That is because q->ma_ops is set to NULL before blk_release_queue is called. blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q); [1]: blk_mq_alloc_and_init_hctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and will be cleaned up in blk_mq_release. [3]: q->nr_hw_queues is 0. [4]: Set q->mq_ops to NULL. [5]: queue_is_mq returns false due to [4]. And blk_mq_release will not be called. The hctxs in q->unused_hctx_list are leaked. To fix it, call blk_release_queue in exception path. | ["https://git.kernel.org/stable/c/2dc97e15a54b7bdf457848aa8c663c98a24e58a6","https://git.kernel.org/stable/c/943f45b9399ed8b2b5190cbc797995edaa97f58f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52939 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: memcg: fix NULL pointer in mem_cgroup_track_foreign_dirty_slowpath() As commit 18365225f044 ("hwpoison, memcg: forcibly uncharge LRU pages"), hwpoison will forcibly uncharg a LRU hwpoisoned page, the folio_memcg could be NULl, then, mem_cgroup_track_foreign_dirty_slowpath() could occurs a NULL pointer dereference, let's do not record the foreign writebacks for folio memcg is null in mem_cgroup_track_foreign_dirty() to fix it. | ["https://git.kernel.org/stable/c/ac86f547ca1002aec2ef66b9e64d03f45bbbfbb9","https://git.kernel.org/stable/c/b79ba5953f6fdc5559389ad415620bffc24f024b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53001 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/drm_vma_manager: Add drm_vma_node_allow_once() Currently there is no easy way for a drm driver to safely check and allow drm_vma_offset_node for a drm file just once. Allow drm drivers to call non-refcounted version of drm_vma_node_allow() so that a driver doesn't need to keep track of each drm_vma_node_allow() to call subsequent drm_vma_node_revoke() to prevent memory leak. | ["https://git.kernel.org/stable/c/67444f8ca31cdaf45e0b761241ad49b1ae04bcf9","https://git.kernel.org/stable/c/899d3a3c19ac0e5da013ce34833dccb97d19b5e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53008 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cifs: fix potential memory leaks in session setup Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. | ["https://git.kernel.org/stable/c/2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f","https://git.kernel.org/stable/c/893d45394dbe4b5cbf3723c19e2ccc8b93a6ac9b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-58097 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix RCU stall while reaping monitor destination ring While processing the monitor destination ring, MSDUs are reaped from the link descriptor based on the corresponding buf_id. However, sometimes the driver cannot obtain a valid buffer corresponding to the buf_id received from the hardware. This causes an infinite loop in the destination processing, resulting in a kernel crash. kernel log: ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309 ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failed Fix this by skipping the problematic buf_id and reaping the next entry, replacing the break with the next MSDU processing. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 | ["https://git.kernel.org/stable/c/16c6c35c03ea73054a1f6d3302a4ce4a331b427d","https://git.kernel.org/stable/c/b4991fc41745645f8050506f5a8578bd11e6b378"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-37925 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: reject on-disk inodes of an unsupported type Syzbot has reported the following BUG: kernel BUG at fs/inode.c:668! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 RIP: 0010:clear_inode+0x168/0x190 Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093 RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38 R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000 R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80 FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0 Call Trace: <TASK> ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This happens when 'clear_inode()' makes an attempt to finalize an underlying JFS inode of unknown type. According to JFS layout description from https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to 15 are reserved for future extensions and should not be encountered on a valid filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'. | ["https://git.kernel.org/stable/c/8987891c4653874d5e3f5d11f063912f4e0b58eb","https://git.kernel.org/stable/c/8c3f9a70d2d4dd6c640afe294b05c6a0a45434d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26641 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 | ["https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6","https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0","https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080","https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0","https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a","https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8","https://git.kernel.org/stable/c/350a6640fac4b53564ec20aa3f4a0922cb0ba5e6","https://git.kernel.org/stable/c/8d975c15c0cd744000ca386247432d57b21f9df0","https://git.kernel.org/stable/c/a9bc32879a08f23cdb80a48c738017e39aea1080","https://git.kernel.org/stable/c/af6b5c50d47ab43e5272ad61935d0ed2e264d3f0","https://git.kernel.org/stable/c/c835df3bcc14858ae9b27315dd7de76370b94f3a","https://git.kernel.org/stable/c/d54e4da98bbfa8c257bdca94c49652d81d18a4d8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241108-0008/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26840 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. | ["https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285","https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3","https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8","https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58","https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579","https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a","https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083","https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444","https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285","https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3","https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8","https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58","https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579","https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec590e25a","https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083","https://git.kernel.org/stable/c/e21a2f17566cbd64926fb8f16323972f7a064444","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3159 | Medium | fixed |
|
A use after free issue was discovered in driver/firewire in outbound_phy_packet_callback in the Linux Kernel. In this flaw a local attacker with special privilege may cause a use after free problem when queue_event() fails. | ["https://github.com/torvalds/linux/commit/b7c81f80246fac44077166f3e07103affe6db8ff","https://github.com/torvalds/linux/commit/b7c81f80246fac44077166f3e07103affe6db8ff"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6238 | Medium | N/A | A buffer overflow vulnerability was found in the NVM Express (NVMe) driver in the Linux kernel. Only privileged user could specify a small meta buffer and let the device perform larger Direct Memory Access (DMA) into the same buffer, overwriting unrelated kernel memory, causing random kernel crashes and memory corruption. | ["https://access.redhat.com/security/cve/CVE-2023-6238","https://bugzilla.redhat.com/show_bug.cgi?id=2250834","https://access.redhat.com/security/cve/CVE-2023-6238","https://bugzilla.redhat.com/show_bug.cgi?id=2250834"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26672 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! | ["https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0","https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53","https://git.kernel.org/stable/c/4f32504a2f85a7b40fe149436881381f48e9c0c0","https://git.kernel.org/stable/c/7b5d58c07024516c0e81b95e98f37710cf402c53"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52588 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to tag gcing flag on page during block migration It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment"). | ["https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde","https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b","https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c","https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136","https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3","https://git.kernel.org/stable/c/417b8a91f4e8831cadaf85c3f15c6991c1f54dde","https://git.kernel.org/stable/c/4961acdd65c956e97c1a000c82d91a8c1cdbe44b","https://git.kernel.org/stable/c/7c972c89457511007dfc933814c06786905e515c","https://git.kernel.org/stable/c/7ea0f29d9fd84905051be020c0df7d557e286136","https://git.kernel.org/stable/c/b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46870 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Disable DMCUB timeout for DCN35 [Why] DMCUB can intermittently take longer than expected to process commands. Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state. [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal. | ["https://git.kernel.org/stable/c/31c254c9cd4b122a10db297124f867107a696d83","https://git.kernel.org/stable/c/7c70e60fbf4bff1123f0e8d5cb1ae71df6164d7f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50183 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. | ["https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6","https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8","https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9","https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56568 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Defer probe of clients after smmu device bound Null pointer dereference occurs due to a race between smmu driver probe and client driver probe, when of_dma_configure() for client is called after the iommu_device_register() for smmu driver probe has executed but before the driver_bound() for smmu driver has been called. Following is how the race occurs: T1:Smmu device probe T2: Client device probe really_probe() arm_smmu_device_probe() iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */ driver_bound() klist_add_tail() When this null smmu pointer is dereferenced later in arm_smmu_probe_device, the device crashes. Fix this by deferring the probe of the client device until the smmu device has bound to the arm smmu driver. [will: Add comment] | ["https://git.kernel.org/stable/c/229e6ee43d2a160a1592b83aad620d6027084aad","https://git.kernel.org/stable/c/4a9485918a042e3114890dfbe19839a1897f8b2c","https://git.kernel.org/stable/c/5018696b19bc6c021e934a8a59f4b1dd8c0ac9f8","https://git.kernel.org/stable/c/c2527d07c7e9cda2c6165d5edccf74752baac1b0","https://git.kernel.org/stable/c/dc02407ea952e20c544a078a6be2e6f008327973","https://git.kernel.org/stable/c/f8f794f387ad21c4696e5cd0626cb6f8a5f6aea5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1859 | Medium | N/A | A use-after-free flaw was found in xen_9pfs_front_removet in net/9p/trans_xen.c in Xen transport for 9pfs in the Linux Kernel. This flaw could allow a local attacker to crash the system due to a race problem, possibly leading to a kernel information leak. | ["https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz%40163.com/","https://lore.kernel.org/all/20230313090002.3308025-1-zyytlz.wz%40163.com/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45886 | High | fixed |
|
An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_net.c has a .disconnect versus dvb_device_open race condition that leads to a use-after-free. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4172385b0c9ac366dcab78eda48c26814b87ed1a","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-3-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26654 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs The dreamcastcard->timer could schedule the spu_dma_work and the spu_dma_work could also arm the dreamcastcard->timer. When the snd_pcm_substream is closing, the aica_channel will be deallocated. But it could still be dereferenced in the worker thread. The reason is that del_timer() will return directly regardless of whether the timer handler is running or not and the worker could be rescheduled in the timer handler. As a result, the UAF bug will happen. The racy situation is shown below: (Thread 1) | (Thread 2) snd_aicapcm_pcm_close() | ... | run_spu_dma() //worker | mod_timer() flush_work() | del_timer() | aica_period_elapsed() //timer kfree(dreamcastcard->channel) | schedule_work() | run_spu_dma() //worker ... | dreamcastcard->channel-> //USE In order to mitigate this bug and other possible corner cases, call mod_timer() conditionally in run_spu_dma(), then implement PCM sync_stop op to cancel both the timer and worker. The sync_stop op will be called from PCM core appropriately when needed. | ["https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457","https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04","https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2","https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901","https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5","https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046","https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845","https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3","https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2","https://git.kernel.org/stable/c/051e0840ffa8ab25554d6b14b62c9ab9e4901457","https://git.kernel.org/stable/c/3c907bf56905de7d27b329afaf59c2fb35d17b04","https://git.kernel.org/stable/c/4206ad65a0ee76920041a755bd3c17c6ba59bba2","https://git.kernel.org/stable/c/61d4787692c1fccdc268ffa7a891f9c149f50901","https://git.kernel.org/stable/c/8c990221681688da34295d6d76cc2f5b963e83f5","https://git.kernel.org/stable/c/9d66ae0e7bb78b54e1e0525456c6b54e1d132046","https://git.kernel.org/stable/c/aa39e6878f61f50892ee2dd9d2176f72020be845","https://git.kernel.org/stable/c/e955e8a7f38a856fc6534ba4e6bffd4d5cc80ac3","https://git.kernel.org/stable/c/eeb2a2ca0b8de7e1c66afaf719529154e7dc60b2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0607 | Medium | fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality. | ["https://access.redhat.com/security/cve/CVE-2024-0607","https://bugzilla.redhat.com/show_bug.cgi?id=2258635","https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63","https://access.redhat.com/security/cve/CVE-2024-0607","https://bugzilla.redhat.com/show_bug.cgi?id=2258635","https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3629 | Low | N/A | A vulnerability was found in Linux Kernel. It has been declared as problematic. This vulnerability affects the function vsock_connect of the file net/vmw_vsock/af_vsock.c. The manipulation leads to memory leak. The complexity of an attack is rather high. The exploitation appears to be difficult. It is recommended to apply a patch to fix this issue. VDB-211930 is the identifier assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d","https://vuldb.com/?ctiid.211930","https://vuldb.com/?id.211930","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=7e97cfed9929eaabc41829c395eb0d1350fccb9d","https://vuldb.com/?ctiid.211930","https://vuldb.com/?id.211930"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0494 | Medium | fixed |
|
A kernel information leak flaw was identified in the scsi_ioctl function in drivers/scsi/scsi_ioctl.c in the Linux kernel. This flaw allows a local attacker with a special user privilege (CAP_SYS_ADMIN or CAP_SYS_RAWIO) to create issues with confidentiality. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2039448","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2039448","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lore.kernel.org/all/20220216084038.15635-1-tcs.kernel%40gmail.com/","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56746 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead. | ["https://git.kernel.org/stable/c/0d3fb3b3e9d66f7b6346e3b90bc0ff48683539ce","https://git.kernel.org/stable/c/29216bb390e36daeebef66abaa02d9751330252b","https://git.kernel.org/stable/c/3dd9df8e5f34c6fc4217a7498c1fb3c352d4afc2","https://git.kernel.org/stable/c/40f4326ed05a3b3537556ff2a844958b9e779a98","https://git.kernel.org/stable/c/bad37309c8b8bf1cfc893750df0951a804009ca0","https://git.kernel.org/stable/c/d10cd53e5a7fb3b7c6f83d4d9a5ea1d97a3ed9a5","https://git.kernel.org/stable/c/d48cbfa90dce506030151915fa3346d67f964af4","https://git.kernel.org/stable/c/f4fbd70e15fafe36a7583954ce189aaf5536aeec","https://git.kernel.org/stable/c/f89d17ae2ac42931be2a0153fecbf8533280c927"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47634 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctl Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ================================================================== The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock held by ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can be concurrent. ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach. ubi_detach is bug-free because it uses reference counting to prevent concurrency. However, uif_init and uif_close in ubi_attach may race with ubi_cdev_ioctl. uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_del And uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3 _______________________|________________________|______________________ ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double free The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubi_get_device in vol_attribute_show and dev_attribute_show.This avoids accessing uninitialized ubi_devices[ubi_num]. ubi_get_device is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack. device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain | ["https://git.kernel.org/stable/c/1a3f1cf87054833242fcd0218de0481cf855f888","https://git.kernel.org/stable/c/3cbf0e392f173ba0ce425968c8374a6aa3e90f2e","https://git.kernel.org/stable/c/432b057f8e847ae5a2306515606f8d2defaca178","https://git.kernel.org/stable/c/5f9e9c223e48c264241d2f34d0bfc29e5fcb5c1b","https://git.kernel.org/stable/c/a8ecee49259f8f78d91ddb329ab2be7e6fd01974","https://git.kernel.org/stable/c/c32fe764191b8ae8b128588beb96e3718d9179d8","https://git.kernel.org/stable/c/d727fd32cbd1abf3465f607021bc9c746f17b5a8","https://git.kernel.org/stable/c/f149b1bd213820363731aa119e5011ca892a2aac"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52438 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binder: fix use-after-free in shinker's callback The mmap read lock is used during the shrinker's callback, which means that using alloc->vma pointer isn't safe as it can race with munmap(). As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap") the mmap lock is downgraded after the vma has been isolated. I was able to reproduce this issue by manually adding some delays and triggering page reclaiming through the shrinker's debug sysfs. The following KASAN report confirms the UAF: ================================================================== BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8 Read of size 8 at addr ffff356ed50e50f0 by task bash/478 CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Hardware name: linux,dummy-virt (DT) Call trace: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc shrinker_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Allocated by task 492: kmem_cache_alloc+0x130/0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Freed by task 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Last potentially related work creation: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi_align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Fix this issue by performing instead a vma_lookup() which will fail to find the vma that was isolated before the mmap lock downgrade. Note that this option has better performance than upgrading to a mmap write lock which would increase contention. Plus, mmap_write_trylock() has been recently removed anyway. | ["https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906","https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6","https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56","https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869","https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3","https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c","https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727","https://git.kernel.org/stable/c/3f489c2067c5824528212b0fc18b28d51332d906","https://git.kernel.org/stable/c/8ad4d580e8aff8de2a4d57c5930fcc29f1ffd4a6","https://git.kernel.org/stable/c/9fa04c93f24138747807fe75b5591bb680098f56","https://git.kernel.org/stable/c/a49087ab93508b60d9b8add91707a22dda832869","https://git.kernel.org/stable/c/a53e15e592b4dcc91c3a3b8514e484a0bdbc53a3","https://git.kernel.org/stable/c/c8c1158ffb007197f31f9d9170cf13e4f34cbb5c","https://git.kernel.org/stable/c/e074686e993ff1be5f21b085a3b1b4275ccd5727","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52637 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER) Lock jsk->sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...) modifies jsk->filters while receiving packets. Following trace was seen on affected system: ================================================================== BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] Read of size 4 at addr ffff888012144014 by task j1939/350 CPU: 0 PID: 350 Comm: j1939 Tainted: G W OE 6.5.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: print_report+0xd3/0x620 ? kasan_complete_mode_report_info+0x7d/0x200 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] kasan_report+0xc2/0x100 ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] __asan_load4+0x84/0xb0 j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939] j1939_sk_recv+0x20b/0x320 [can_j1939] ? __kasan_check_write+0x18/0x20 ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939] ? j1939_simple_recv+0x69/0x280 [can_j1939] ? j1939_ac_recv+0x5e/0x310 [can_j1939] j1939_can_recv+0x43f/0x580 [can_j1939] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] ? raw_rcv+0x42/0x3c0 [can_raw] ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939] can_rcv_filter+0x11f/0x350 [can] can_receive+0x12f/0x190 [can] ? __pfx_can_rcv+0x10/0x10 [can] can_rcv+0xdd/0x130 [can] ? __pfx_can_rcv+0x10/0x10 [can] __netif_receive_skb_one_core+0x13d/0x150 ? __pfx___netif_receive_skb_one_core+0x10/0x10 ? __kasan_check_write+0x18/0x20 ? _raw_spin_lock_irq+0x8c/0xe0 __netif_receive_skb+0x23/0xb0 process_backlog+0x107/0x260 __napi_poll+0x69/0x310 net_rx_action+0x2a1/0x580 ? __pfx_net_rx_action+0x10/0x10 ? __pfx__raw_spin_lock+0x10/0x10 ? handle_irq_event+0x7d/0xa0 __do_softirq+0xf3/0x3f8 do_softirq+0x53/0x80 </IRQ> <TASK> __local_bh_enable_ip+0x6e/0x70 netif_rx+0x16b/0x180 can_send+0x32b/0x520 [can] ? __pfx_can_send+0x10/0x10 [can] ? __check_object_size+0x299/0x410 raw_sendmsg+0x572/0x6d0 [can_raw] ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] ? apparmor_socket_sendmsg+0x2f/0x40 ? __pfx_raw_sendmsg+0x10/0x10 [can_raw] sock_sendmsg+0xef/0x100 sock_write_iter+0x162/0x220 ? __pfx_sock_write_iter+0x10/0x10 ? __rtnl_unlock+0x47/0x80 ? security_file_permission+0x54/0x320 vfs_write+0x6ba/0x750 ? __pfx_vfs_write+0x10/0x10 ? __fget_light+0x1ca/0x1f0 ? __rcu_read_unlock+0x5b/0x280 ksys_write+0x143/0x170 ? __pfx_ksys_write+0x10/0x10 ? __kasan_check_read+0x15/0x20 ? fpregs_assert_state_consistent+0x62/0x70 __x64_sys_write+0x47/0x60 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6d/0x90 ? irqentry_exit+0x3f/0x50 ? exc_page_fault+0x79/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 348: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_alloc_info+0x1f/0x30 __kasan_kmalloc+0xb5/0xc0 __kmalloc_node_track_caller+0x67/0x160 j1939_sk_setsockopt+0x284/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 349: kasan_save_stack+0x2a/0x50 kasan_set_track+0x29/0x40 kasan_save_free_info+0x2f/0x50 __kasan_slab_free+0x12e/0x1c0 __kmem_cache_free+0x1b9/0x380 kfree+0x7a/0x120 j1939_sk_setsockopt+0x3b2/0x450 [can_j1939] __sys_setsockopt+0x15c/0x2f0 __x64_sys_setsockopt+0x6b/0x80 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 | ["https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532","https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8","https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed","https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba","https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc","https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50","https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d","https://git.kernel.org/stable/c/08de58abedf6e69396e1207e4f99ef8904b2b532","https://git.kernel.org/stable/c/41ccb5bcbf03f02d820bc6ea8390811859f558f8","https://git.kernel.org/stable/c/4dd684d4bb3cd5454e0bf6e2a1bdfbd5c9c872ed","https://git.kernel.org/stable/c/978e50ef8c38dc71bd14d1b0143d554ff5d188ba","https://git.kernel.org/stable/c/efe7cf828039aedb297c1f9920b638fffee6aabc","https://git.kernel.org/stable/c/f84e7534457dcd7835be743517c35378bb4e7c50","https://git.kernel.org/stable/c/fc74b9cb789cae061bbca7b203a3842e059f6b5d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26598 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt. | ["https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4","https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1","https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f","https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703","https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88","https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6","https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80","https://git.kernel.org/stable/c/12c2759ab1343c124ed46ba48f27bd1ef5d2dff4","https://git.kernel.org/stable/c/65b201bf3e9af1b0254243a5881390eda56f72d1","https://git.kernel.org/stable/c/ad362fe07fecf0aba839ff2cc59a3617bd42c33f","https://git.kernel.org/stable/c/ba7be666740847d967822bed15500656b26bc703","https://git.kernel.org/stable/c/d04acadb6490aa3314f9c9e087691e55de153b88","https://git.kernel.org/stable/c/dba788e25f05209adf2b0175eb1691dc89fb1ba6","https://git.kernel.org/stable/c/dd3956a1b3dd11f46488c928cb890d6937d1ca80","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52475 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Input: powermate - fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e | ["https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46","https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd","https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc","https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc","https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f","https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9","https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06","https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8","https://git.kernel.org/stable/c/2efe67c581a2a6122b328d4bb6f21b3f36f40d46","https://git.kernel.org/stable/c/5aa514100aaf59868d745196258269a16737c7bd","https://git.kernel.org/stable/c/5c15c60e7be615f05a45cd905093a54b11f461bc","https://git.kernel.org/stable/c/67cace72606baf1758fd60feb358f4c6be92e1cc","https://git.kernel.org/stable/c/6a4a396386404e62fb59bc3bde48871a64a82b4f","https://git.kernel.org/stable/c/8677575c4f39d65bf0d719b5d20e8042e550ccb9","https://git.kernel.org/stable/c/cd2fbfd8b922b7fdd50732e47d797754ab59cb06","https://git.kernel.org/stable/c/e528b1b9d60743e0b26224e3fe7aa74c24b8b2f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26883 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on 32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem. | ["https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a","https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895","https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d","https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0","https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a","https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b","https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae","https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3","https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d","https://git.kernel.org/stable/c/0971126c8164abe2004b8536b49690a0d6005b0a","https://git.kernel.org/stable/c/15641007df0f0d35fa28742b25c2a7db9dcd6895","https://git.kernel.org/stable/c/21e5fa4688e1a4d3db6b72216231b24232f75c1d","https://git.kernel.org/stable/c/43f798b9036491fb014b55dd61c4c5c3193267d0","https://git.kernel.org/stable/c/7070b274c7866a4c5036f8d54fcaf315c64ac33a","https://git.kernel.org/stable/c/7a4b21250bf79eef26543d35bd390448646c536b","https://git.kernel.org/stable/c/ca1f06e72dec41ae4f76e7b1a8a97265447b46ae","https://git.kernel.org/stable/c/d0e214acc59145ce25113f617311aa79dda39cb3","https://git.kernel.org/stable/c/f06899582ccee09bd85d0696290e3eaca9aa042d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52602 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix slab-out-of-bounds Read in dtSearch Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO | ["https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb","https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6","https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd","https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7","https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472","https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612","https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950","https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f","https://git.kernel.org/stable/c/1b9d6828589d57f94a23fb1c46112cda39d7efdb","https://git.kernel.org/stable/c/1c40ca3d39d769931b28295b3145c25f1decf5a6","https://git.kernel.org/stable/c/6c6a96c3d74df185ee344977d46944d6f33bb4dd","https://git.kernel.org/stable/c/7110650b85dd2f1cee819acd1345a9013a1a62f7","https://git.kernel.org/stable/c/bff9d4078a232c01e42e9377d005fb2f4d31a472","https://git.kernel.org/stable/c/cab0c265ba182fd266c2aa3c69d7e40640a7f612","https://git.kernel.org/stable/c/ce8bc22e948634a5c0a3fa58a179177d0e3f3950","https://git.kernel.org/stable/c/fa5492ee89463a7590a1449358002ff7ef63529f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-22705 | High | fixed |
|
An issue was discovered in ksmbd in the Linux kernel before 6.6.10. smb2_get_data_area_len in fs/smb/server/smb2misc.c can cause an smb_strndup_from_utf16 out-of-bounds access because the relationship between Name data and CreateContexts data is mishandled. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d10c77873ba1e9e6b91905018e29e196fd5f863d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26852 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/ipv6: avoid possible UAF in ip6_route_mpath_notify() syzbot found another use-after-free in ip6_route_mpath_notify() [1] Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause. We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase. [1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037 CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK> Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m ---truncated--- | ["https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136","https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18","https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda","https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e","https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab","https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe","https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24","https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a","https://git.kernel.org/stable/c/31ea5bcc7d4cd1423de6be327a2c034725704136","https://git.kernel.org/stable/c/394334fe2ae3b9f1e2332b873857e84cb28aac18","https://git.kernel.org/stable/c/61b34f73cdbdb8eaf9ea12e9e2eb3b29716c4dda","https://git.kernel.org/stable/c/664f9c647260cc9d68b4e31d9899530d89dd045e","https://git.kernel.org/stable/c/685f7d531264599b3f167f1e94bbd22f120e5fab","https://git.kernel.org/stable/c/79ce2e54cc0ae366f45516c00bf1b19aa43e9abe","https://git.kernel.org/stable/c/cae3303257950d03ffec2df4a45e836f10d26c24","https://git.kernel.org/stable/c/ed883060c38721ed828061f6c0c30e5147326c9a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52594 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt | ["https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234","https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348","https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1","https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9","https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1","https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d","https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225","https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc","https://git.kernel.org/stable/c/25c6f49ef59b7a9b80a3f7ab9e95268a1b01a234","https://git.kernel.org/stable/c/2adc886244dff60f948497b59affb6c6ebb3c348","https://git.kernel.org/stable/c/84770a996ad8d7f121ff2fb5a8d149aad52d64c1","https://git.kernel.org/stable/c/9003fa9a0198ce004b30738766c67eb7373479c9","https://git.kernel.org/stable/c/be609c7002dd4504b15b069cb7582f4c778548d1","https://git.kernel.org/stable/c/e4f4bac7d3b64eb75f70cd3345712de6f68a215d","https://git.kernel.org/stable/c/f11f0fd1ad6c11ae7856d4325fe9d05059767225","https://git.kernel.org/stable/c/f44f073c78112ff921a220d01b86d09f2ace59bc","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52600 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix uaf in jfs_evict_inode When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. | ["https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e","https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce","https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35","https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61","https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f","https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e","https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8","https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3","https://git.kernel.org/stable/c/1696d6d7d4a1b373e96428d0fe1166bd7c3c795e","https://git.kernel.org/stable/c/32e8f2d95528d45828c613417cb2827d866cbdce","https://git.kernel.org/stable/c/81b4249ef37297fb17ba102a524039a05c6c5d35","https://git.kernel.org/stable/c/8e44dc3f96e903815dab1d74fff8faafdc6feb61","https://git.kernel.org/stable/c/93df0a2a0b3cde2d7ab3a52ed46ea1d6d4aaba5f","https://git.kernel.org/stable/c/bacdaa04251382d7efd4f09f9a0686bfcc297e2e","https://git.kernel.org/stable/c/bc6ef64dbe71136f327d63b2b9071b828af2c2a8","https://git.kernel.org/stable/c/e0e1958f4c365e380b17ccb35617345b31ef7bf3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52464 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr': drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); ... 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); ... Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] | ["https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5","https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8","https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6","https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a","https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21","https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601","https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398","https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057","https://git.kernel.org/stable/c/426fae93c01dffa379225eb2bd4d3cdc42c6eec5","https://git.kernel.org/stable/c/475c58e1a471e9b873e3e39958c64a2d278275c8","https://git.kernel.org/stable/c/5da3b6e7196f0b4f3728e4e25eb20233a9ddfaf6","https://git.kernel.org/stable/c/6aa7865ba7ff7f0ede0035180fb3b9400ceb405a","https://git.kernel.org/stable/c/700cf4bead80fac994dcc43ae1ca5d86d8959b21","https://git.kernel.org/stable/c/71c17ee02538802ceafc830f0736aa35b564e601","https://git.kernel.org/stable/c/9dbac9fdae6e3b411fc4c3fca3bf48f70609c398","https://git.kernel.org/stable/c/e1c86511241588efffaa49556196f09a498d5057","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52642 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: rc: bpf attach/detach requires write permission Note that bpf attach/detach also requires CAP_NET_ADMIN. | ["https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f","https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8","https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f","https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e","https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be","https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0","https://git.kernel.org/stable/c/6a9d552483d50953320b9d3b57abdee8d436f23f","https://git.kernel.org/stable/c/93136132d1b5792bf44151e3494ae3691cd738e8","https://git.kernel.org/stable/c/93d8109bf182510629bbefc8cd45296d2393987f","https://git.kernel.org/stable/c/9f6087851ec6dce5b15f694aeaf3e8ec8243224e","https://git.kernel.org/stable/c/caf2da1d4562de4e35eedec0be2b7f1ee25d83be","https://git.kernel.org/stable/c/d98210108e7b2ff64b332b0a3541c8ad6a0617b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52612 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: scomp - fix req->dst buffer overflow The req->dst buffer size should be checked before copying from the scomp_scratch->dst to avoid req->dst buffer overflow problem. | ["https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe","https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e","https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5","https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883","https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131","https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759","https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625","https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76","https://git.kernel.org/stable/c/1142d65c5b881590962ad763f94505b6dd67d2fe","https://git.kernel.org/stable/c/4518dc468cdd796757190515a9be7408adc8911e","https://git.kernel.org/stable/c/4df0c942d04a67df174195ad8082f6e30e7f71a5","https://git.kernel.org/stable/c/71c6670f9f032ec67d8f4e3f8db4646bf5a62883","https://git.kernel.org/stable/c/744e1885922a9943458954cfea917b31064b4131","https://git.kernel.org/stable/c/7d9e5bed036a7f9e2062a137e97e3c1e77fb8759","https://git.kernel.org/stable/c/a5f2f91b3fd7387e5102060809316a0f8f0bc625","https://git.kernel.org/stable/c/e0e3f4a18784182cfe34e20c00eca11e78d53e76","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52445 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix use after free on context disconnection Upon module load, a kthread is created targeting the pvr2_context_thread_func function, which may call pvr2_context_destroy and thus call kfree() on the context object. However, that might happen before the usb hub_event handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack. | ["https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795","https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e","https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb","https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c","https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d","https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1","https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08","https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab","https://git.kernel.org/stable/c/2cf0005d315549b8d2b940ff96a66c2a889aa795","https://git.kernel.org/stable/c/30773ea47d41773f9611ffb4ebc9bda9d19a9e7e","https://git.kernel.org/stable/c/3233d8bf7893550045682192cb227af7fa3defeb","https://git.kernel.org/stable/c/437b5f57732bb4cc32cc9f8895d2010ee9ff521c","https://git.kernel.org/stable/c/47aa8fcd5e8b5563af4042a00f25ba89bef8f33d","https://git.kernel.org/stable/c/ded85b0c0edd8f45fec88783d7555a5b982449c1","https://git.kernel.org/stable/c/ec3634ebe23fc3c44ebc67c6d25917300bc68c08","https://git.kernel.org/stable/c/ec36c134dd020d28e312c2f1766f85525e747aab","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52599 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: jfs: fix array-index-out-of-bounds in diNewExt [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the value is invalid, exit the subsequent process. Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter). | ["https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641","https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402","https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe","https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b","https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98","https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017","https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e","https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41","https://git.kernel.org/stable/c/3537f92cd22c672db97fae6997481e678ad14641","https://git.kernel.org/stable/c/49f9637aafa6e63ba686c13cb8549bf5e6920402","https://git.kernel.org/stable/c/5a6660139195f5e2fbbda459eeecb8788f3885fe","https://git.kernel.org/stable/c/6996d43b14486f4a6655b10edc541ada1b580b4b","https://git.kernel.org/stable/c/6aa30020879042d46df9f747e4f0a486eea6fe98","https://git.kernel.org/stable/c/de6a91aed1e0b1a23e9c11e7d7557f088eeeb017","https://git.kernel.org/stable/c/e2b77d107b33bb31c8b1f5c4cb8f277b23728f1e","https://git.kernel.org/stable/c/f423528488e4f9606cef858eceea210bf1163f41","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49168 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not clean up repair bio if submit fails The submit helper will always run bio_endio() on the bio if it fails to submit, so cleaning up the bio just leads to a variety of use-after-free and NULL pointer dereference bugs because we race with the endio function that is cleaning up the bio. Instead just return BLK_STS_OK as the repair function has to continue to process the rest of the pages, and the endio for the repair bio will do the appropriate cleanup for the page that it was given. | ["https://git.kernel.org/stable/c/7170875083254b51fcc5d67f96640977083f481e","https://git.kernel.org/stable/c/8cbc3001a3264d998d6b6db3e23f935c158abd4d","https://git.kernel.org/stable/c/d1cb11fb45ebbb1e7dfe5e9038b32ea72c184b14","https://git.kernel.org/stable/c/e76c78c48902dae6fa612749f59162bca0a79e0b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49328 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mt76: fix use-after-free by removing a non-RCU wcid pointer Fixes an issue caught by KASAN about use-after-free in mt76_txq_schedule by protecting mtxq->wcid with rcu_lock between mt76_txq_schedule and sta_info_[alloc, free]. [18853.876689] ================================================================== [18853.876751] BUG: KASAN: use-after-free in mt76_txq_schedule+0x204/0xaf8 [mt76] [18853.876773] Read of size 8 at addr ffffffaf989a2138 by task mt76-tx phy0/883 [18853.876786] [18853.876810] CPU: 5 PID: 883 Comm: mt76-tx phy0 Not tainted 5.10.100-fix-510-56778d365941-kasan #5 0b01fbbcf41a530f52043508fec2e31a4215 [18853.876840] Call trace: [18853.876861] dump_backtrace+0x0/0x3ec [18853.876878] show_stack+0x20/0x2c [18853.876899] dump_stack+0x11c/0x1ac [18853.876918] print_address_description+0x74/0x514 [18853.876934] kasan_report+0x134/0x174 [18853.876948] __asan_report_load8_noabort+0x44/0x50 [18853.876976] mt76_txq_schedule+0x204/0xaf8 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877002] mt76_txq_schedule_all+0x2c/0x48 [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877030] mt7921_tx_worker+0xa0/0x1cc [mt7921_common f0875ebac9d7b4754e1010549e7db50fbd90a047] [18853.877054] __mt76_worker_fn+0x190/0x22c [mt76 074e03e4640e97fe7405ee1fab547b81c4fa45d2] [18853.877071] kthread+0x2f8/0x3b8 [18853.877087] ret_from_fork+0x10/0x30 [18853.877098] [18853.877112] Allocated by task 941: [18853.877131] kasan_save_stack+0x38/0x68 [18853.877147] __kasan_kmalloc+0xd4/0xfc [18853.877163] kasan_kmalloc+0x10/0x1c [18853.877177] __kmalloc+0x264/0x3c4 [18853.877294] sta_info_alloc+0x460/0xf88 [mac80211] [18853.877410] ieee80211_prep_connection+0x204/0x1ee0 [mac80211] [18853.877523] ieee80211_mgd_auth+0x6c4/0xa4c [mac80211] [18853.877635] ieee80211_auth+0x20/0x2c [mac80211] [18853.877733] rdev_auth+0x7c/0x438 [cfg80211] [18853.877826] cfg80211_mlme_auth+0x26c/0x390 [cfg80211] [18853.877919] nl80211_authenticate+0x6d4/0x904 [cfg80211] [18853.877938] genl_rcv_msg+0x748/0x93c [18853.877954] netlink_rcv_skb+0x160/0x2a8 [18853.877969] genl_rcv+0x3c/0x54 [18853.877985] netlink_unicast_kernel+0x104/0x1ec [18853.877999] netlink_unicast+0x178/0x268 [18853.878015] netlink_sendmsg+0x3cc/0x5f0 [18853.878030] sock_sendmsg+0xb4/0xd8 [18853.878043] ____sys_sendmsg+0x2f8/0x53c [18853.878058] ___sys_sendmsg+0xe8/0x150 [18853.878071] __sys_sendmsg+0xc4/0x1f4 [18853.878087] __arm64_compat_sys_sendmsg+0x88/0x9c [18853.878101] el0_svc_common+0x1b4/0x390 [18853.878115] do_el0_svc_compat+0x8c/0xdc [18853.878131] el0_svc_compat+0x10/0x1c [18853.878146] el0_sync_compat_handler+0xa8/0xcc [18853.878161] el0_sync_compat+0x188/0x1c0 [18853.878171] [18853.878183] Freed by task 10927: [18853.878200] kasan_save_stack+0x38/0x68 [18853.878215] kasan_set_track+0x28/0x3c [18853.878228] kasan_set_free_info+0x24/0x48 [18853.878244] __kasan_slab_free+0x11c/0x154 [18853.878259] kasan_slab_free+0x14/0x24 [18853.878273] slab_free_freelist_hook+0xac/0x1b0 [18853.878287] kfree+0x104/0x390 [18853.878402] sta_info_free+0x198/0x210 [mac80211] [18853.878515] __sta_info_destroy_part2+0x230/0x2d4 [mac80211] [18853.878628] __sta_info_flush+0x300/0x37c [mac80211] [18853.878740] ieee80211_set_disassoc+0x2cc/0xa7c [mac80211] [18853.878851] ieee80211_mgd_deauth+0x4a4/0x10a0 [mac80211] [18853.878962] ieee80211_deauth+0x20/0x2c [mac80211] [18853.879057] rdev_deauth+0x7c/0x438 [cfg80211] [18853.879150] cfg80211_mlme_deauth+0x274/0x414 [cfg80211] [18853.879243] cfg80211_mlme_down+0xe4/0x118 [cfg80211] [18853.879335] cfg80211_disconnect+0x218/0x2d8 [cfg80211] [18853.879427] __cfg80211_leave+0x17c/0x240 [cfg80211] [18853.879519] cfg80211_leave+0x3c/0x58 [cfg80211] [18853.879611] wiphy_suspend+0xdc/0x200 [cfg80211] [18853.879628] dpm_run_callback+0x58/0x408 [18853.879642] __device_suspend+0x4cc/0x864 [18853.879658] async_suspend+0x34/0xf4 [18 ---truncated--- | ["https://git.kernel.org/stable/c/4448327b41738dbfcda680eb4935ff835568f468","https://git.kernel.org/stable/c/51fb1278aa57ae0fc54adaa786e1965362bed4fb","https://git.kernel.org/stable/c/d5f77f1dbb59feae81f88e44551e8e1d8a802d9a","https://git.kernel.org/stable/c/e55bcdd0bf34a8b10d45ce80ebb3164c5292a17d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26754 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 | ["https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec","https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca","https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a","https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576","https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77","https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e","https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861","https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7","https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec","https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca","https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a","https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576","https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77","https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e","https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861","https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52439 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: uio: Fix use-after-free in uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister will kfree idev when the idev->dev kobject ref is 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, the idev will be double freed. To address this issue, we can get idev atomic & inc idev reference with minor_lock. | ["https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2","https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea","https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c","https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad","https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7","https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570","https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41","https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50","https://git.kernel.org/stable/c/0c9ae0b8605078eafc3bea053cc78791e97ba2e2","https://git.kernel.org/stable/c/17a8519cb359c3b483fb5c7367efa9a8a508bdea","https://git.kernel.org/stable/c/3174e0f7de1ba392dc191625da83df02d695b60c","https://git.kernel.org/stable/c/35f102607054faafe78d2a6994b18d5d9d6e92ad","https://git.kernel.org/stable/c/5cf604ee538ed0c467abe3b4cda5308a6398f0f7","https://git.kernel.org/stable/c/5e0be1229ae199ebb90b33102f74a0f22d152570","https://git.kernel.org/stable/c/913205930da6213305616ac539447702eaa85e41","https://git.kernel.org/stable/c/e93da893d52d82d57fc0db2ca566024e0f26ff50","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://security.netapp.com/advisory/ntap-20241227-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42071 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ionic: use dev_consume_skb_any outside of napi If we're not in a NAPI softirq context, we need to be careful about how we call napi_consume_skb(), specifically we need to call it with budget==0 to signal to it that we're not in a safe context. This was found while running some configuration stress testing of traffic and a change queue config loop running, and this curious note popped out: [ 4371.402645] BUG: using smp_processor_id() in preemptible [00000000] code: ethtool/20545 [ 4371.402897] caller is napi_skb_cache_put+0x16/0x80 [ 4371.403120] CPU: 25 PID: 20545 Comm: ethtool Kdump: loaded Tainted: G OE 6.10.0-rc3-netnext+ #8 [ 4371.403302] Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 01/23/2021 [ 4371.403460] Call Trace: [ 4371.403613] <TASK> [ 4371.403758] dump_stack_lvl+0x4f/0x70 [ 4371.403904] check_preemption_disabled+0xc1/0xe0 [ 4371.404051] napi_skb_cache_put+0x16/0x80 [ 4371.404199] ionic_tx_clean+0x18a/0x240 [ionic] [ 4371.404354] ionic_tx_cq_service+0xc4/0x200 [ionic] [ 4371.404505] ionic_tx_flush+0x15/0x70 [ionic] [ 4371.404653] ? ionic_lif_qcq_deinit.isra.23+0x5b/0x70 [ionic] [ 4371.404805] ionic_txrx_deinit+0x71/0x190 [ionic] [ 4371.404956] ionic_reconfigure_queues+0x5f5/0xff0 [ionic] [ 4371.405111] ionic_set_ringparam+0x2e8/0x3e0 [ionic] [ 4371.405265] ethnl_set_rings+0x1f1/0x300 [ 4371.405418] ethnl_default_set_doit+0xbb/0x160 [ 4371.405571] genl_family_rcv_msg_doit+0xff/0x130 [...] I found that ionic_tx_clean() calls napi_consume_skb() which calls napi_skb_cache_put(), but before that last call is the note /* Zero budget indicate non-NAPI context called us, like netpoll */ and DEBUG_NET_WARN_ON_ONCE(!in_softirq()); Those are pretty big hints that we're doing it wrong. We can pass a context hint down through the calls to let ionic_tx_clean() know what we're doing so it can call napi_consume_skb() correctly. | ["https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821","https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a","https://git.kernel.org/stable/c/84b767f9e34fdb143c09e66a2a20722fc2921821","https://git.kernel.org/stable/c/ef7646ed49fff962e97b276f4ab91327a67eeb5a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47637 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ubifs: Fix deadlock in concurrent rename whiteout and inode writeback Following hung tasks: [ 77.028764] task:kworker/u8:4 state:D stack: 0 pid: 132 [ 77.028820] Call Trace: [ 77.029027] schedule+0x8c/0x1b0 [ 77.029067] mutex_lock+0x50/0x60 [ 77.029074] ubifs_write_inode+0x68/0x1f0 [ubifs] [ 77.029117] __writeback_single_inode+0x43c/0x570 [ 77.029128] writeback_sb_inodes+0x259/0x740 [ 77.029148] wb_writeback+0x107/0x4d0 [ 77.029163] wb_workfn+0x162/0x7b0 [ 92.390442] task:aa state:D stack: 0 pid: 1506 [ 92.390448] Call Trace: [ 92.390458] schedule+0x8c/0x1b0 [ 92.390461] wb_wait_for_completion+0x82/0xd0 [ 92.390469] __writeback_inodes_sb_nr+0xb2/0x110 [ 92.390472] writeback_inodes_sb_nr+0x14/0x20 [ 92.390476] ubifs_budget_space+0x705/0xdd0 [ubifs] [ 92.390503] do_rename.cold+0x7f/0x187 [ubifs] [ 92.390549] ubifs_rename+0x8b/0x180 [ubifs] [ 92.390571] vfs_rename+0xdb2/0x1170 [ 92.390580] do_renameat2+0x554/0x770 , are caused by concurrent rename whiteout and inode writeback processes: rename_whiteout(Thread 1) wb_workfn(Thread2) ubifs_rename do_rename lock_4_inodes (Hold ui_mutex) ubifs_budget_space make_free_space shrink_liability __writeback_inodes_sb_nr bdi_split_work_to_wbs (Queue new wb work) wb_do_writeback(wb work) __writeback_single_inode ubifs_write_inode LOCK(ui_mutex) ↑ wb_wait_for_completion (Wait wb work) <-- deadlock! Reproducer (Detail program in [Link]): 1. SYS_renameat2("/mp/dir/file", "/mp/dir/whiteout", RENAME_WHITEOUT) 2. Consume out of space before kernel(mdelay) doing budget for whiteout Fix it by doing whiteout space budget before locking ubifs inodes. BTW, it also fixes wrong goto tag 'out_release' in whiteout budget error handling path(It should at least recover dir i_size and unlock 4 ubifs inodes). | ["https://git.kernel.org/stable/c/37bdf1ad592555ecda1d55b89f6e393e4c0589d1","https://git.kernel.org/stable/c/70e9090acc32348cedc5def0cd6d5c126efc97b9","https://git.kernel.org/stable/c/83e42a78428fc354f5e2049935b84c8d8d29b787","https://git.kernel.org/stable/c/8b278c8dcfb565cb65eceb62a38cbf7a7c326db5","https://git.kernel.org/stable/c/9dddc8211430fb851ddf0b168e3a00c6f66cc185","https://git.kernel.org/stable/c/afd427048047e8efdedab30e8888044e2be5aa9c","https://git.kernel.org/stable/c/c58af8564a7b08757173009030b74baf4b2b762b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49305 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192u: Fix deadlock in ieee80211_beacons_stop() There is a deadlock in ieee80211_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | ieee80211_send_beacon() ieee80211_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | ieee80211_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, ieee80211_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. | ["https://git.kernel.org/stable/c/042915c1bfedd684c1d98a841794ee203200571a","https://git.kernel.org/stable/c/1fbe033c52480f7954c057510040fa6286c4ea25","https://git.kernel.org/stable/c/66f769762f65d957f688f3258755c6ec410bf710","https://git.kernel.org/stable/c/806c7b53414934ba2a39449b31fd1a038e500273","https://git.kernel.org/stable/c/b34cb54923a6e5ddefbaf358c85c922c6ab456e2","https://git.kernel.org/stable/c/b465bb2ebf666116c1ac745cb80c65154dc0d27e","https://git.kernel.org/stable/c/ffc9cab7243f8151be37966301307bfd3cda2db3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49316 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4: Don't hold the layoutget locks across multiple RPC calls When doing layoutget as part of the open() compound, we have to be careful to release the layout locks before we can call any further RPC calls, such as setattr(). The reason is that those calls could trigger a recall, which could deadlock. | ["https://git.kernel.org/stable/c/08d7a26d115cc7892668baa9750f64bd8baca29b","https://git.kernel.org/stable/c/0ee5b9644f06b4d3cdcd9544f43f63312e425a4c","https://git.kernel.org/stable/c/6949493884fe88500de4af182588e071cf1544ee","https://git.kernel.org/stable/c/6b3fc1496e7227cd6a39a80bbfb7588ef7c7a010","https://git.kernel.org/stable/c/a2b3be930e79cc5d9d829f158e31172b2043f0cd","https://git.kernel.org/stable/c/d4c2a041ed3ba114502d5ed6ace5b1a48d637a8e","https://git.kernel.org/stable/c/ea759ae0a9ae5acee677d722129710ac89cc59c1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49322 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Fix sleeping function called from invalid context on RT kernel When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30 </TASK> | ["https://git.kernel.org/stable/c/12025abdc8539ed9d5014e2d647a3fd1bd3de5cd","https://git.kernel.org/stable/c/1788e6dbb61286215442b1af99e51405a6206762","https://git.kernel.org/stable/c/40f9fde06b25884baa0c4bd138b909a9b67218b4","https://git.kernel.org/stable/c/43bfc4dccc416c964b53cbdc430e814f8b6f770b","https://git.kernel.org/stable/c/48c6ee7d6c614f09b2c8553a95eefef6ecf196e0","https://git.kernel.org/stable/c/9abf3db8bdb63ab545034148ef2118f4d088ca59","https://git.kernel.org/stable/c/9b534640a2c6a8d88168febc82ec6d161184f2ec","https://git.kernel.org/stable/c/be1f323fb9d9b14a505ca22d742d321769454de1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49371 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: driver core: fix deadlock in __device_attach In __device_attach function, The lock holding logic is as follows: ... __device_attach device_lock(dev) // get lock dev async_schedule_dev(__device_attach_async_helper, dev); // func async_schedule_node async_schedule_node_domain(func) entry = kzalloc(sizeof(struct async_entry), GFP_ATOMIC); /* when fail or work limit, sync to execute func, but __device_attach_async_helper will get lock dev as well, which will lead to A-A deadlock. */ if (!entry || atomic_read(&entry_count) > MAX_WORK) { func; else queue_work_node(node, system_unbound_wq, &entry->work) device_unlock(dev) As shown above, when it is allowed to do async probes, because of out of memory or work limit, async work is not allowed, to do sync execute instead. it will lead to A-A deadlock because of __device_attach_async_helper getting lock dev. To fix the deadlock, move the async_schedule_dev outside device_lock, as we can see, in async_schedule_node_domain, the parameter of queue_work_node is system_unbound_wq, so it can accept concurrent operations. which will also not change the code logic, and will not lead to deadlock. | ["https://git.kernel.org/stable/c/34fdd9b7def9d2fcb71bb7b0bc4848dd7313767e","https://git.kernel.org/stable/c/36ee9ffca8ef56c302f2855c4a5fccf61c0c1ada","https://git.kernel.org/stable/c/593b595332bd2d65e1a5c1ae7897996c157f5468","https://git.kernel.org/stable/c/b232b02bf3c205b13a26dcec08e53baddd8e59ed","https://git.kernel.org/stable/c/d53a227bfcd5160ce1b61d9954901968a20651e7","https://git.kernel.org/stable/c/df6de52b80aa3b46f5ac804412355ffe2e1df93e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21820 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: xilinx_uartps: split sysrq handling lockdep detects the following circular locking dependency: CPU 0 CPU 1 ========================== ============================ cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock() The fixed commit attempts to avoid this situation by only taking the port lock in cdns_uart_console_write if port->sysrq unset. However, if (as shown above) cdns_uart_console_write runs before port->sysrq is set, then it will try to take the port lock anyway. This may result in a deadlock. Fix this by splitting sysrq handling into two parts. We use the prepare helper under the port lock and defer handling until we release the lock. | ["https://git.kernel.org/stable/c/4410dba9807a17a93f649a9f5870ceaf30a675a3","https://git.kernel.org/stable/c/8ea0e7b3d7b8f2f0fc9db491ff22a0abe120801c","https://git.kernel.org/stable/c/9b88a7c4584ba67267a051069b8abe44fc9595b2","https://git.kernel.org/stable/c/b06f388994500297bb91be60ffaf6825ecfd2afe","https://git.kernel.org/stable/c/de5bd24197bd9ee37ec1e379a3d882bbd15c5065","https://git.kernel.org/stable/c/e22a97700901ba5e8bf8db68056a0d50f9440cae"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49309 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback() There is a deadlock in rtw_surveydone_event_callback(), which is shown below: (Thread 1) | (Thread 2) | _set_timer() rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ... We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_surveydone_event_callback() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() in rtw_scan_timeout_handler() to spin_lock_irq(). Otherwise, spin_lock_bh() will also cause deadlock() in timer handler. | ["https://git.kernel.org/stable/c/2c41f5c341853f84b7bc2f32605d4e2782e8c279","https://git.kernel.org/stable/c/c84e5c819600ee0628f61b33d145258ae0f3d7a7","https://git.kernel.org/stable/c/cc7ad0d77b51c872d629bcd98aea463a3c4109e7","https://git.kernel.org/stable/c/ce129d3efd181da5fd56f4360cc8827122afa67e","https://git.kernel.org/stable/c/f89f6c3ebf69623b8ea48200bd690e9e210335a1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49327 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bcache: avoid journal no-space deadlock by reserving 1 journal bucket The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation. When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens. The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore. This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time. During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock. | ["https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159","https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6","https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363","https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce","https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49446 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvdimm: Fix firmware activation deadlock scenarios Lockdep reports the following deadlock scenarios for CXL root device power-management, device_prepare(), operations, and device_shutdown() operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key); These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec() which walks the entire system device topology taking device_lock() along the way. The nvdimm_bus_lock() is protecting against unregistration, multiple simultaneous ops callers, and preventing activate_show() from racing activate_store(). For the first 2, the lock is redundant. Unregistration already flushes all ops users, and sysfs already prevents multiple threads to be active in an ops handler at the same time. For the last userspace should already be waiting for its last activate_store() to complete, and does not need activate_show() to flush the write side, so this lock usage can be deleted in these attributes. | ["https://git.kernel.org/stable/c/2f97ebc58d5fc83ca1528cd553fa725472ab3ca8","https://git.kernel.org/stable/c/2fd853fdb40afc052de338693df1372f2ead7be7","https://git.kernel.org/stable/c/641649f31e20df630310f5c22f26c071acc676d4","https://git.kernel.org/stable/c/ceb924ee16b2c8e48dcac3d9ad6be01c40b5a228","https://git.kernel.org/stable/c/e6829d1bd3c4b58296ee9e412f7ed4d6cb390192"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3707 | Medium | fixed |
|
A double-free memory flaw was found in the Linux kernel. The Intel GVT-g graphics driver triggers VGA card system resource overload, causing a fail in the intel_gvt_dma_map_guest_page function. This issue could allow a local user to crash the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2137979","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2137979","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20221007013708.1946061-1-zyytlz.wz%40163.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4127 | Medium | fixed |
|
A NULL pointer dereference issue was discovered in the Linux kernel in io_files_update_with_index_alloc. A local user could use this flaw to potentially crash the system causing a denial of service. | ["https://github.com/torvalds/linux/commit/d785a773bed966a75ca1f11d108ae1897189975b","https://lore.kernel.org/all/d5a19c1e-9968-e22e-5917-c3139c5e7e89%40kernel.dk/","https://github.com/torvalds/linux/commit/d785a773bed966a75ca1f11d108ae1897189975b","https://lore.kernel.org/all/d5a19c1e-9968-e22e-5917-c3139c5e7e89%40kernel.dk/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1095 | Medium | fixed |
|
In nf_tables_updtable, if nf_tables_table_enable returns an error, nft_trans_destroy is called to free the transaction object. nft_trans_destroy() calls list_del(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a NULL pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2173973","https://github.com/torvalds/linux/commit/580077855a40741cf511766129702d97ff02f4d9","https://bugzilla.redhat.com/show_bug.cgi?id=2173973","https://github.com/torvalds/linux/commit/580077855a40741cf511766129702d97ff02f4d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2905 | Medium | fixed |
|
An out-of-bounds memory read flaw was found in the Linux kernel's BPF subsystem in how a user calls the bpf_tail_call function with a key larger than the max_entries of the map. This flaw allows a local user to gain unauthorized access to data. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2121800","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/","https://bugzilla.redhat.com/show_bug.cgi?id=2121800","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/bpf/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel%40iogearbox.net/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-47632 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/set_memory: Avoid spinlock recursion in change_page_attr() Commit 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") included a spin_lock() to change_page_attr() in order to safely perform the three step operations. But then commit 9f7853d7609d ("powerpc/mm: Fix set_memory_*() against concurrent accesses") modify it to use pte_update() and do the operation safely against concurrent access. In the meantime, Maxime reported some spinlock recursion. [ 15.351649] BUG: spinlock recursion on CPU#0, kworker/0:2/217 [ 15.357540] lock: init_mm+0x3c/0x420, .magic: dead4ead, .owner: kworker/0:2/217, .owner_cpu: 0 [ 15.366563] CPU: 0 PID: 217 Comm: kworker/0:2 Not tainted 5.15.0+ #523 [ 15.373350] Workqueue: events do_free_init [ 15.377615] Call Trace: [ 15.380232] [e4105ac0] [800946a4] do_raw_spin_lock+0xf8/0x120 (unreliable) [ 15.387340] [e4105ae0] [8001f4ec] change_page_attr+0x40/0x1d4 [ 15.393413] [e4105b10] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.400009] [e4105b60] [80169620] free_pcp_prepare+0x1e4/0x4a0 [ 15.406045] [e4105ba0] [8016c5a0] free_unref_page+0x40/0x2b8 [ 15.411979] [e4105be0] [8018724c] kasan_depopulate_vmalloc_pte+0x6c/0x94 [ 15.418989] [e4105c00] [801424e0] __apply_to_page_range+0x164/0x310 [ 15.425451] [e4105c50] [80187834] kasan_release_vmalloc+0xbc/0x134 [ 15.431898] [e4105c70] [8015f7a8] __purge_vmap_area_lazy+0x4e4/0xdd8 [ 15.438560] [e4105d30] [80160d10] _vm_unmap_aliases.part.0+0x17c/0x24c [ 15.445283] [e4105d60] [801642d0] __vunmap+0x2f0/0x5c8 [ 15.450684] [e4105db0] [800e32d0] do_free_init+0x68/0x94 [ 15.456181] [e4105dd0] [8005d094] process_one_work+0x4bc/0x7b8 [ 15.462283] [e4105e90] [8005d614] worker_thread+0x284/0x6e8 [ 15.468227] [e4105f00] [8006aaec] kthread+0x1f0/0x210 [ 15.473489] [e4105f40] [80017148] ret_from_kernel_thread+0x14/0x1c Remove the read / modify / write sequence to make the operation atomic and remove the spin_lock() in change_page_attr(). To do the operation atomically, we can't use pte modification helpers anymore. Because all platforms have different combination of bits, it is not easy to use those bits directly. But all have the _PAGE_KERNEL_{RO/ROX/RW/RWX} set of flags. All we need it to compare two sets to know which bits are set or cleared. For instance, by comparing _PAGE_KERNEL_ROX and _PAGE_KERNEL_RO you know which bit gets cleared and which bit get set when changing exec permission. | ["https://git.kernel.org/stable/c/6def4eaf0391f24be541633a954c0e4876858b1e","https://git.kernel.org/stable/c/6ebe5ca2cbe438a688f2ae238ef5a0b0b5f3468a","https://git.kernel.org/stable/c/96917107e67846f1d959ed03be281048efad14c5","https://git.kernel.org/stable/c/a4c182ecf33584b9b2d1aa9dad073014a504c01f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49311 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192bs: Fix deadlock in rtw_joinbss_event_prehandle() There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below: (Thread 1) | (Thread 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ... We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_joinbss_event_prehandle() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() to spin_lock_irq() in _rtw_join_timeout_handler() in order to prevent deadlock. | ["https://git.kernel.org/stable/c/041879b12ddb0c6c83ed9c0bdd10dc82a056f2fc","https://git.kernel.org/stable/c/1f6c99b94ca3caad346876b3e22e3ca3d25bc8ee","https://git.kernel.org/stable/c/ae60744d5fad840b9d056d35b4b652d95e755846","https://git.kernel.org/stable/c/eca9748d9267a38d532464e3305a38629e9c35a9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49536 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock During stress I/O tests with 500+ vports, hard LOCKUP call traces are observed. CPU A: native_queued_spin_lock_slowpath+0x192 _raw_spin_lock_irqsave+0x32 lpfc_handle_fcp_err+0x4c6 lpfc_fcp_io_cmd_wqe_cmpl+0x964 lpfc_sli4_fp_handle_cqe+0x266 __lpfc_sli4_process_cq+0x105 __lpfc_sli4_hba_process_cq+0x3c lpfc_cq_poll_hdler+0x16 irq_poll_softirq+0x76 __softirqentry_text_start+0xe4 irq_exit+0xf7 do_IRQ+0x7f CPU B: native_queued_spin_lock_slowpath+0x5b _raw_spin_lock+0x1c lpfc_abort_handler+0x13e scmd_eh_abort_handler+0x85 process_one_work+0x1a7 worker_thread+0x30 kthread+0x112 ret_from_fork+0x1f Diagram of lockup: CPUA CPUB ---- ---- lpfc_cmd->buf_lock phba->hbalock lpfc_cmd->buf_lock phba->hbalock Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock first before phba->hbalock. | ["https://git.kernel.org/stable/c/03cbbd7c2f5ee288f648f4aeedc765a181188553","https://git.kernel.org/stable/c/0c4eed901285b9cae36a622f32bea3e92490da6c","https://git.kernel.org/stable/c/21c0d469349957b5dc811c41200a2a998996ca8d","https://git.kernel.org/stable/c/7625e81de2164a082810e1f27547d388406da610"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49542 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Move cfg_log_verbose check before calling lpfc_dmp_dbg() In an attempt to log message 0126 with LOG_TRACE_EVENT, the following hard lockup call trace hangs the system. Call Trace: _raw_spin_lock_irqsave+0x32/0x40 lpfc_dmp_dbg.part.32+0x28/0x220 [lpfc] lpfc_cmpl_els_fdisc+0x145/0x460 [lpfc] lpfc_sli_cancel_jobs+0x92/0xd0 [lpfc] lpfc_els_flush_cmd+0x43c/0x670 [lpfc] lpfc_els_flush_all_cmd+0x37/0x60 [lpfc] lpfc_sli4_async_event_proc+0x956/0x1720 [lpfc] lpfc_do_work+0x1485/0x1d70 [lpfc] kthread+0x112/0x130 ret_from_fork+0x1f/0x40 Kernel panic - not syncing: Hard LOCKUP The same CPU tries to claim the phba->port_list_lock twice. Move the cfg_log_verbose checks as part of the lpfc_printf_vlog() and lpfc_printf_log() macros before calling lpfc_dmp_dbg(). There is no need to take the phba->port_list_lock within lpfc_dmp_dbg(). | ["https://git.kernel.org/stable/c/09c772557a4fd9490fed1bfb133268313ea22213","https://git.kernel.org/stable/c/271725e4028559ae7974d762a8467dc9de412f2e","https://git.kernel.org/stable/c/cc6501afccec55b8b6c90584cbf71f1fefa77d1e","https://git.kernel.org/stable/c/e294647b1aed4247fe52851f3a3b2b19ae906228"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49475 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-qspi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. | ["https://git.kernel.org/stable/c/10f537219629769498ecb8515e096be213224c24","https://git.kernel.org/stable/c/33dda87d04598ac5d9a849218a373443f7d3de66","https://git.kernel.org/stable/c/560dcbe1c7a78f597f2167371ebdbe2bca3d0735","https://git.kernel.org/stable/c/9d9c84825c3ec359b165c762a424cfdefe87fdd7","https://git.kernel.org/stable/c/a2b331ac11e1cac56f5b7d367e9f3c5796deaaed"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49304 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: tty: serial: Fix deadlock in sa1100_set_termios() There is a deadlock in sa1100_set_termios(), which is shown below: (Thread 1) | (Thread 2) | sa1100_enable_ms() sa1100_set_termios() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | sa1100_timeout() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold sport->port.lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need sport->port.lock in position (2) of thread 2. As a result, sa1100_set_termios() will block forever. This patch moves del_timer_sync() before spin_lock_irqsave() in order to prevent the deadlock. | ["https://git.kernel.org/stable/c/0976808d0d171ec837d4bd3e9f4ad4a00ab703b8","https://git.kernel.org/stable/c/09a5958a2452ad22d0cb638711ef34ea1863a829","https://git.kernel.org/stable/c/2cbfc38df580bff5b2fe19f21c1a7520efcc4b3b","https://git.kernel.org/stable/c/34d91e555e5582cffdbcbb75517bc9217866823e","https://git.kernel.org/stable/c/553213432ef0c295becdc08c0207d2094468f673","https://git.kernel.org/stable/c/62b2caef400c1738b6d22f636c628d9f85cd4c4c","https://git.kernel.org/stable/c/6e2273eefab54a521d9c59efb6e1114e742bdf41","https://git.kernel.org/stable/c/85e20f8bd31a46d8c60103d0274a8ebe8f47f2b2","https://git.kernel.org/stable/c/920f0ae7a129ffee98a106e3bbdfd61a2a59e939"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49313 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: usb: host: Fix deadlock in oxu_bus_suspend() There is a deadlock in oxu_bus_suspend(), which is shown below: (Thread 1) | (Thread 2) | timer_action() oxu_bus_suspend() | mod_timer() spin_lock_irq() //(1) | (wait a time) ... | oxu_watchdog() del_timer_sync() | spin_lock_irq() //(2) (wait timer to stop) | ... We hold oxu->lock in position (1) of thread 1, and use del_timer_sync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxu_bus_suspend() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irq(), which could let timer handler to obtain the needed lock. | ["https://git.kernel.org/stable/c/2dcec0bc142be2096af71a5703d63237127db204","https://git.kernel.org/stable/c/4187b291a76664a3c03d3f0d9bfadc8322881868","https://git.kernel.org/stable/c/4d378f2ae58138d4c55684e1d274e7dd94aa6524","https://git.kernel.org/stable/c/9b58d255f27b0ed6a2e43208960864d67579db58","https://git.kernel.org/stable/c/a3d380188bde8900c3f604e82b56572896499124","https://git.kernel.org/stable/c/b97aae8b43b718314012e8170b7e03dbfd2e7677","https://git.kernel.org/stable/c/d888753872190abd18f68a7d77b9c7c367f0a7ab","https://git.kernel.org/stable/c/f8242044c91cafbba9e320b0fb31abf2429a3221","https://git.kernel.org/stable/c/ffe9440d698274c6462d2e304562c6ddfc8c84df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49315 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192e: Fix deadlock in rtllib_beacons_stop() There is a deadlock in rtllib_beacons_stop(), which is shown below: (Thread 1) | (Thread 2) | rtllib_send_beacon() rtllib_beacons_stop() | mod_timer() spin_lock_irqsave() //(1) | (wait a time) ... | rtllib_send_beacon_cb() del_timer_sync() | spin_lock_irqsave() //(2) (wait timer to stop) | ... We hold ieee->beacon_lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need ieee->beacon_lock in position (2) of thread 2. As a result, rtllib_beacons_stop() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_irqsave(), which could let timer handler to obtain the needed lock. | ["https://git.kernel.org/stable/c/08bacf871c019163ccd1389d0bc957a43324967a","https://git.kernel.org/stable/c/0f69d7d5e918aa43423d86bd17ddb11b1b5e8ada","https://git.kernel.org/stable/c/381045dc64d23a2229c47c5524c06bfc33d34446","https://git.kernel.org/stable/c/4681129fda9e8555392eaaadb239ec6a6e2b3e12","https://git.kernel.org/stable/c/46c861009bf437a18417df24cea0d181741b7d72","https://git.kernel.org/stable/c/64b05fa212c7e4d057676e8b7e7120c6eb2f615b","https://git.kernel.org/stable/c/9b6bdbd9337de3917945847bde262a34a87a6303","https://git.kernel.org/stable/c/fef451f0fbbe85dbd2962b18379d02e2965610db","https://git.kernel.org/stable/c/ffd4c4d5293e4985092ea45ba21cad9326e2e434"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2785 | Medium | fixed |
|
There exists an arbitrary memory read within the Linux Kernel BPF - Constants provided to fill pointers in structs passed in to bpf_sys_bpf are not verified and can point anywhere, including memory not owned by BPF. An attacker with CAP_BPF can arbitrarily read memory from anywhere on the system. We recommend upgrading past commit 86f44fcec22c | ["https://git.kernel.org/bpf/bpf/c/86f44fcec22c","https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei%40google.com/T/#t","https://git.kernel.org/bpf/bpf/c/86f44fcec22c","https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei%40google.com/T/#t"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3847 | High | N/A | An unauthorized access to the execution of the setuid file with capabilities flaw in the Linux kernel OverlayFS subsystem was found in the way user copying a capable file from a nosuid mount into another mount. A local user could use this flaw to escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2009704","https://www.openwall.com/lists/oss-security/2021/10/14/3","https://bugzilla.redhat.com/show_bug.cgi?id=2009704","https://www.openwall.com/lists/oss-security/2021/10/14/3"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-28390 | High | N/A | ems_usb_start_xmit in drivers/net/can/usb/ems_usb.c in the Linux kernel through 5.17.1 has a double free. | ["https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/c70222752228a62135cee3409dccefd494a24646","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2194 | Medium | fixed |
|
An out-of-bounds write vulnerability was found in the Linux kernel's SLIMpro I2C device driver. The userspace "data->block[0]" variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2188396","https://github.com/torvalds/linux/commit/92fbb6d1296f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.redhat.com/show_bug.cgi?id=2188396","https://github.com/torvalds/linux/commit/92fbb6d1296f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50057 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 | ["https://git.kernel.org/stable/c/4d4b23c119542fbaed2a16794d3801cb4806ea02","https://git.kernel.org/stable/c/b72bf5cade51ba4055c8a8998d275e72e6b521ce","https://git.kernel.org/stable/c/db63d9868f7f310de44ba7bea584e2454f8b4ed0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3533 | Medium | fixed |
|
A vulnerability was found in Linux Kernel. It has been rated as problematic. This issue affects the function parse_usdt_arg of the file tools/lib/bpf/usdt.c of the component BPF. The manipulation of the argument reg_name leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211031. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=0dc9254e03704c75f2ebc9cbef2ce4de83fba603","https://vuldb.com/?id.211031","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=0dc9254e03704c75f2ebc9cbef2ce4de83fba603","https://vuldb.com/?id.211031"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3355 | Medium | fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msm_gem_submit.c code in the submit_lookup_cmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system. | ["https://access.redhat.com/security/cve/CVE-2023-3355","https://bugzilla.redhat.com/show_bug.cgi?id=2217820","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be","https://access.redhat.com/security/cve/CVE-2023-3355","https://bugzilla.redhat.com/show_bug.cgi?id=2217820","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d839f0811a31322c087a859c2b181e2383daa7be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3543 | Medium | fixed |
|
A vulnerability, which was classified as problematic, has been found in Linux Kernel. This issue affects the function unix_sock_destructor/unix_release_sock of the file net/unix/af_unix.c of the component BPF. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-211043. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=7a62ed61367b8fd01bae1e18e30602c25060d824","https://vuldb.com/?id.211043","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=7a62ed61367b8fd01bae1e18e30602c25060d824","https://vuldb.com/?id.211043"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48502 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.2. The ntfs3 subsystem does not properly check for correctness during disk reads, leading to an out-of-bounds read in ntfs_set_ea in fs/ntfs3/xattr.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b","https://security.netapp.com/advisory/ntap-20230703-0004/","https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0e8235d28f3a0e9eda9f02ff67ee566d5f42b66b","https://security.netapp.com/advisory/ntap-20230703-0004/","https://syzkaller.appspot.com/bug?extid=8778f030156c6cd16d72"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26669 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: flower: Fix chain template offload When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter. However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2]. Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one. As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains. [1] unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab374e>] __kmalloc+0x4e/0x90 [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0 [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0 [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320 [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90 [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0 [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460 [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0 [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180 [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280 [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340 [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0 [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170 [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0 [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440 [<ffffffff83ac6270>] netlink_unicast+0x540/0x820 [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0 [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80 [2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev ---truncated--- | ["https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8","https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97","https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01","https://git.kernel.org/stable/c/32f2a0afa95fae0d1ceec2ff06e0e816939964b8","https://git.kernel.org/stable/c/9ed46144cff3598a5cf79955630e795ff9af5b97","https://git.kernel.org/stable/c/c04709b2cc99ae31c346f79f0211752d7b74df01"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1838 | High | fixed |
|
A use-after-free flaw was found in vhost_net_set_backend in drivers/vhost/net.c in virtio network subcomponent in the Linux kernel due to a double fget. This flaw could allow a local attacker to crash the system, and could even lead to a kernel information leak problem. | ["https://lore.kernel.org/netdev/20220516084213.26854-1-jasowang%40redhat.com/T/","https://security.netapp.com/advisory/ntap-20230517-0003/","https://lore.kernel.org/netdev/20220516084213.26854-1-jasowang%40redhat.com/T/","https://security.netapp.com/advisory/ntap-20230517-0003/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0168 | Medium | fixed |
|
A denial of service (DOS) issue was found in the Linux kernel’s smb2_ioctl_query_info function in the fs/cifs/smb2ops.c Common Internet File System (CIFS) due to an incorrect return from the memdup_user function. This flaw allows a local, privileged (CAP_SYS_ADMIN) attacker to crash the system. | ["https://access.redhat.com/security/cve/CVE-2022-0168","https://bugzilla.redhat.com/show_bug.cgi?id=2037386","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6f5e358452479fa8a773b5c6ccc9e4ec5a20880","https://access.redhat.com/security/cve/CVE-2022-0168","https://bugzilla.redhat.com/show_bug.cgi?id=2037386","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6f5e358452479fa8a773b5c6ccc9e4ec5a20880"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45884 | High | N/A | An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvbdev.c has a use-after-free, related to dvb_register_device dynamically allocating fops. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=627bb528b086b4136315c25d6a447a98ea9448d3","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-4-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45885 | High | N/A | An issue was discovered in the Linux kernel through 6.0.9. drivers/media/dvb-core/dvb_frontend.c has a race condition that can cause a use-after-free when a device is disconnected. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-2-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35827 | High | fixed |
|
An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in drivers/net/ethernet/renesas/ravb_main.c. | ["https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/","https://security.netapp.com/advisory/ntap-20230803-0003/","https://www.spinics.net/lists/netdev/msg886947.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://lore.kernel.org/lkml/cca0b40b-d6f8-54c7-1e46-83cb62d0a2f1%40huawei.com/T/","https://security.netapp.com/advisory/ntap-20230803-0003/","https://www.spinics.net/lists/netdev/msg886947.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52586 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: Add mutex lock in control vblank irq Add a mutex lock to control vblank irq to synchronize vblank enable/disable operations happening from different threads to prevent race conditions while registering/unregistering the vblank irq callback. v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a parameter of dpu_encoder_phys. -Switch from atomic refcnt to a simple int counter as mutex has now been added v3: Mistakenly did not change wording in last version. It is done now. v2: Slightly changed wording of commit message Patchwork: https://patchwork.freedesktop.org/patch/571854/ | ["https://git.kernel.org/stable/c/14f109bf74dd67e1d0469fed859c8e506b0df53f","https://git.kernel.org/stable/c/45284ff733e4caf6c118aae5131eb7e7cf3eea5a","https://git.kernel.org/stable/c/14f109bf74dd67e1d0469fed859c8e506b0df53f","https://git.kernel.org/stable/c/45284ff733e4caf6c118aae5131eb7e7cf3eea5a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6531 | High | fixed |
|
A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-6531","https://bugzilla.redhat.com/show_bug.cgi?id=2253034","https://lore.kernel.org/all/c716c88321939156909cfa1bd8b0faaf1c804103.1701868795.git.asml.silence@gmail.com/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-6531","https://bugzilla.redhat.com/show_bug.cgi?id=2253034","https://lore.kernel.org/all/c716c88321939156909cfa1bd8b0faaf1c804103.1701868795.git.asml.silence@gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-7192 | Medium | fixed |
|
A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:1188","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-7192","https://bugzilla.redhat.com/show_bug.cgi?id=2256279","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:1188","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-7192","https://bugzilla.redhat.com/show_bug.cgi?id=2256279","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ac4893980bbe79ce383daf9a0885666a30fe4c83"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-28389 | Medium | N/A | mcba_usb_start_xmit in drivers/net/can/usb/mcba_usb.c in the Linux kernel through 5.17.1 has a double free. | ["https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/04c9b00ba83594a29813d6b1fb8fdc93a3915174","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-45402 | Medium | fixed |
|
The check_alu_op() function in kernel/bpf/verifier.c in the Linux kernel through v5.16-rc5 did not properly update bounds while handling the mov32 instruction, which allows local users to obtain potentially sensitive address information, aka a "pointer leak." | ["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3cf2b61eb06765e27fec6799292d9fb46d0b7e60","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b1a7288dedc6caf9023f2676b4f5ed34cf0d4029","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=e572ff80f05c33cd0cb4860f864f5c9c044280b6","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3cf2b61eb06765e27fec6799292d9fb46d0b7e60","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=b1a7288dedc6caf9023f2676b4f5ed34cf0d4029","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=e572ff80f05c33cd0cb4860f864f5c9c044280b6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling code from control queue handler") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: <TASK> ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... </TASK> ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes] | ["https://git.kernel.org/stable/c/00fb5b23e1c9cdbe496f5cd6b40367cb895f6c93","https://git.kernel.org/stable/c/221af82f606d928ccef19a16d35633c63026f1be","https://git.kernel.org/stable/c/25613e6d9841a1f9fb985be90df921fa99f800de","https://git.kernel.org/stable/c/46128370a72c431df733af5ebb065c4d48c9ad39","https://git.kernel.org/stable/c/61517f33e76d2c5247c1e61e668693afe5b67e6f","https://git.kernel.org/stable/c/6592347f06e2b19a624270a85ad4b3ae48c3b241","https://git.kernel.org/stable/c/ace9c778a214da9c98d7b69d904d1b0816f4f681"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50153 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Fix null-ptr-deref in target_alloc_device() There is a null-ptr-deref issue reported by KASAN: BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod] ... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0 ... entry_SYSCALL_64_after_hwframe+0x76/0x7e In target_alloc_device(), if allocing memory for dev queues fails, then dev will be freed by dev->transport->free_device(), but dev->transport is not initialized at that time, which will lead to a null pointer reference problem. Fixing this bug by freeing dev with hba->backend->ops->free_device(). | ["https://git.kernel.org/stable/c/14a6a2adb440e4ae97bee73b2360946bd033dadd","https://git.kernel.org/stable/c/39e02fa90323243187c91bb3e8f2f5f6a9aacfc7","https://git.kernel.org/stable/c/895ab729425ef9bf3b6d2f8d0853abe64896f314","https://git.kernel.org/stable/c/8c1e6717f60d31f8af3937c23c4f1498529584e1","https://git.kernel.org/stable/c/b80e9bc85bd9af378e7eac83e15dd129557bbdb6","https://git.kernel.org/stable/c/fca6caeb4a61d240f031914413fcc69534f6dc03"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3357 | Medium | N/A | A NULL pointer dereference flaw was found in the Linux kernel AMD Sensor Fusion Hub driver. This flaw allows a local user to crash the system. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53ffa6a9f83b2170c60591da1ead8791d5a42e81","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=53ffa6a9f83b2170c60591da1ead8791d5a42e81"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49123 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ath11k: Fix frames flush failure caused by deadlock We are seeing below warnings: kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0 kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0 this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_work has no chance to run in 5 seconds. By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasing ATH11K_FLUSH_TIMEOUT to 50 we get below warnings: kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds. kernel: [ 120.763169] Not tainted 5.10.90 #12 kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0 kernel: [ 120.763201] Call Trace: kernel: [ 120.763214] __schedule+0x785/0x12fa kernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bb kernel: [ 120.763242] schedule+0x7e/0xa1 kernel: [ 120.763253] schedule_timeout+0x98/0xfe kernel: [ 120.763266] ? run_local_timers+0x4a/0x4a kernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a] kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2e kernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c] kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2 kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be] kernel: [ 120.763802] ? genl_rcv+0x36/0x36 kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7 kernel: [ 120.763829] genl_rcv+0x28/0x36 kernel: [ 120.763840] netlink_unicast+0x179/0x24b kernel: [ 120.763854] netlink_sendmsg+0x393/0x401 kernel: [ 120.763872] sock_sendmsg+0x72/0x76 kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6 kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2 kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1 kernel: [ 120.763940] __sys_sendmsg+0x85/0xbf kernel: [ 120.763956] do_syscall_64+0x43/0x55 kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9 kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83 kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002e kernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83 kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009 kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000 kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980 kernel: [ 120.764032] R13: 00007ffe604 ---truncated--- | ["https://git.kernel.org/stable/c/261b07519518bd14cb168b287b17e1d195f8d0c8","https://git.kernel.org/stable/c/33e723dc054edfc94da90eecca3b72cb424ce4a3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49296 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: fix possible deadlock when holding Fwb to get inline_data 1, mount with wsync. 2, create a file with O_RDWR, and the request was sent to mds.0: ceph_atomic_open()--> ceph_mdsc_do_request(openc) finish_open(file, dentry, ceph_open)--> ceph_open()--> ceph_init_file()--> ceph_init_file_info()--> ceph_uninline_data()--> { ... if (inline_version == 1 || /* initial version, no data */ inline_version == CEPH_INLINE_NONE) goto out_unlock; ... } The inline_version will be 1, which is the initial version for the new create file. And here the ci->i_inline_version will keep with 1, it's buggy. 3, buffer write to the file immediately: ceph_write_iter()--> ceph_get_caps(file, need=Fw, want=Fb, ...); generic_perform_write()--> a_ops->write_begin()--> ceph_write_begin()--> netfs_write_begin()--> netfs_begin_read()--> netfs_rreq_submit_slice()--> netfs_read_from_server()--> rreq->netfs_ops->issue_read()--> ceph_netfs_issue_read()--> { ... if (ci->i_inline_version != CEPH_INLINE_NONE && ceph_netfs_issue_op_inline(subreq)) return; ... } ceph_put_cap_refs(ci, Fwb); The ceph_netfs_issue_op_inline() will send a getattr(Fsr) request to mds.1. 4, then the mds.1 will request the rd lock for CInode::filelock from the auth mds.0, the mds.0 will do the CInode::filelock state transation from excl --> sync, but it need to revoke the Fxwb caps back from the clients. While the kernel client has aleady held the Fwb caps and waiting for the getattr(Fsr). It's deadlock! URL: https://tracker.ceph.com/issues/55377 | ["https://git.kernel.org/stable/c/292b7a7275ce535a1abfa4dd0b2e586162aaae1e","https://git.kernel.org/stable/c/825978fd6a0defc3c29d8a38b6cea76a0938d21e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49303 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drivers: staging: rtl8192eu: Fix deadlock in rtw_joinbss_event_prehandle There is a deadlock in rtw_joinbss_event_prehandle(), which is shown below: (Thread 1) | (Thread 2) | _set_timer() rtw_joinbss_event_prehandle()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_join_timeout_handler() | _rtw_join_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ... We hold pmlmepriv->lock in position (1) of thread 1 and use del_timer_sync() to wait timer to stop, but timer handler also need pmlmepriv->lock in position (2) of thread 2. As a result, rtw_joinbss_event_prehandle() will block forever. This patch extracts del_timer_sync() from the protection of spin_lock_bh(), which could let timer handler to obtain the needed lock. What`s more, we change spin_lock_bh() to spin_lock_irq() in _rtw_join_timeout_handler() in order to prevent deadlock. | ["https://git.kernel.org/stable/c/0fcddf9c7c10202946d5b19409efbdff744fba88","https://git.kernel.org/stable/c/25cf414b0610fea29d8e045f315648d9007c9a46"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49496 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko If the driver support subdev mode, the parameter "dev->pm.dev" will be NULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmod mtk-vcodec-dec.ko. [ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80 [ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c [ 4380.711509] sp : ffff80000819bc10 [ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000 [ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220 [ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020 [ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976 [ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040 [ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc [ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208 [ 4380.786031] Call trace: [ 4380.788465] do_raw_spin_trylock+0x4/0x80 [ 4380.792462] __pm_runtime_disable+0x2c/0x1b0 [ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec] [ 4380.802466] platform_remove+0x2c/0x60 [ 4380.806204] __device_release_driver+0x194/0x250 [ 4380.810810] driver_detach+0xc8/0x15c [ 4380.814462] bus_remove_driver+0x5c/0xb0 [ 4380.818375] driver_unregister+0x34/0x64 [ 4380.822288] platform_driver_unregister+0x18/0x24 [ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec] [ 4380.833240] __arm64_sys_delete_module+0x190/0x224 [ 4380.838020] invoke_syscall+0x48/0x114 [ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c [ 4380.846540] do_el0_svc+0x28/0x90 [ 4380.849844] el0_svc+0x4c/0x100 [ 4380.852975] el0t_64_sync_handler+0xec/0xf0 [ 4380.857148] el0t_64_sync+0x190/0x194 [ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004) | ["https://git.kernel.org/stable/c/1fa37b00dc55a061a3eb82e378849862b4aeca9d","https://git.kernel.org/stable/c/c10c0086db688c95bb4e0e378e523818dff1551d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49531 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: loop: implement ->free_disk Ensure that the lo_device which is stored in the gendisk private data is valid until the gendisk is freed. Currently the loop driver uses a lot of effort to make sure a device is not freed when it is still in use, but to to fix a potential deadlock this will be relaxed a bit soon. | ["https://git.kernel.org/stable/c/aadd1443aae7fe8956e3b11157827067f034406a","https://git.kernel.org/stable/c/d2c7f56f8b5256d57f9e3fc7794c31361d43bdd9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49746 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: imx-sdma: Fix a possible memory leak in sdma_transfer_init If the function sdma_load_context() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed. We already met the sdma_load_context() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ... In this case, the desc->bd will not be freed without this change. | ["https://git.kernel.org/stable/c/1417f59ac0b02130ee56c0c50794b9b257be3d17","https://git.kernel.org/stable/c/43acd767bd90c5d4172ce7fee5d9007a9a08dea9","https://git.kernel.org/stable/c/80ee99e52936b2c04cc37b17a14b2ae2f9d282ac","https://git.kernel.org/stable/c/bd0050b7ffa87c7b260d563646af612f4112a778","https://git.kernel.org/stable/c/ce4745a6b8016fae74c95dcd457d4ceef7d98af1","https://git.kernel.org/stable/c/dbe634ce824329d8f14079c3e9f8f11670894bec"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49751 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: w1: fix WARNING after calling w1_process() I got the following WARNING message while removing driver(ds2482): ------------[ cut here ]------------ do not call blocking ops when !TASK_RUNNING; state=1 set at [<000000002d50bfb6>] w1_process+0x9e/0x1d0 [wire] WARNING: CPU: 0 PID: 262 at kernel/sched/core.c:9817 __might_sleep+0x98/0xa0 CPU: 0 PID: 262 Comm: w1_bus_master1 Tainted: G N 6.1.0-rc3+ #307 RIP: 0010:__might_sleep+0x98/0xa0 Call Trace: exit_signals+0x6c/0x550 do_exit+0x2b4/0x17e0 kthread_exit+0x52/0x60 kthread+0x16d/0x1e0 ret_from_fork+0x1f/0x30 The state of task is set to TASK_INTERRUPTIBLE in loop in w1_process(), set it to TASK_RUNNING when it breaks out of the loop to avoid the warning. | ["https://git.kernel.org/stable/c/190b5c3bbd5df685bb1063bda048831d72b8f1d4","https://git.kernel.org/stable/c/216f35db6ec6a667cd9db4838d657c1d2f4684da","https://git.kernel.org/stable/c/276052159ba94d4d9f5b453fb4707d6798c6b845","https://git.kernel.org/stable/c/36225a7c72e9e3e1ce4001b6ce72849f5c9a2d3b","https://git.kernel.org/stable/c/89c62cee5d4d65ac75d99b5f986f7f94290e888f","https://git.kernel.org/stable/c/bccd6df4c177b1ad766f16565ccc298653d027d0","https://git.kernel.org/stable/c/cfc7462ff824ed6718ed0272ee9aae88e20d469a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49757 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: EDAC/highbank: Fix memory leak in highbank_mc_probe() When devres_open_group() fails, it returns -ENOMEM without freeing memory allocated by edac_mc_alloc(). Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ] | ["https://git.kernel.org/stable/c/0db40e23b56d217eebd385bebb64057ef764b2c7","https://git.kernel.org/stable/c/329fbd260352a7b9a83781d8b8bd96f95844a51f","https://git.kernel.org/stable/c/8d23f5d25264beb223ee79cdb530b88c237719fc","https://git.kernel.org/stable/c/b7863ef8a8f0fee96b4eb41211f4918c0e047253","https://git.kernel.org/stable/c/caffa7fed1397d1395052272c93900176de86557","https://git.kernel.org/stable/c/e7a293658c20a7945014570e1921bf7d25d68a36","https://git.kernel.org/stable/c/f1b3e23ed8df87d779ee86ac37f379e79a24169a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: macvlan: fix memory leaks of macvlan_common_newlink kmemleak reports memory leaks in macvlan_common_newlink, as follows: ip link add link eth0 name .. type macvlan mode source macaddr add <MAC-ADDR> kmemleak reports: unreferenced object 0xffff8880109bb140 (size 64): comm "ip", pid 284, jiffies 4294986150 (age 430.108s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff ..........Z..... 80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b ..............kk backtrace: [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300 [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0 [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170 [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0 [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20 [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50 [<ffffffff81d98278>] rtnl_newlink+0x48/0x70 ... In the scenario where the macvlan mode is configured as 'source', macvlan_changelink_sources() will be execured to reconfigure list of remote source mac addresses, at the same time, if register_netdevice() return an error, the resource generated by macvlan_changelink_sources() is not cleaned up. Using this patch, in the case of an error, it will execute macvlan_flush_sources() to ensure that the resource is cleaned up. | ["https://git.kernel.org/stable/c/21d3a8b6a1e39e7529ce9de07316ee13a63f305b","https://git.kernel.org/stable/c/23569b5652ee8e8e55a12f7835f59af6f3cefc30","https://git.kernel.org/stable/c/685e73e3f7a9fb75cbf049a9d0b7c45cc6b57b2e","https://git.kernel.org/stable/c/956e0216a19994443c90ba2ea6b0b284c9c4f9cb","https://git.kernel.org/stable/c/9ea003c4671b2fc455320ecf6d4a43b0a3c1878a","https://git.kernel.org/stable/c/9f288e338be206713d79b29144c27fca4503c39b","https://git.kernel.org/stable/c/a81b44d1df1f07f00c0dcc0a0b3d2fa24a46289e","https://git.kernel.org/stable/c/a8d67367ab33604326cc37ab44fd1801bf5691ba"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: mv_xor_v2: Fix a resource leak in mv_xor_v2_remove() A clk_prepare_enable() call in the probe is not balanced by a corresponding clk_disable_unprepare() in the remove function. Add the missing call. | ["https://git.kernel.org/stable/c/04f2cc56d80a1ac058045a7835c5bfd910f17863","https://git.kernel.org/stable/c/081195d17a0c4c636da2b869bd5809d42e8cbb13","https://git.kernel.org/stable/c/0b7ee3d50f32d277bf024b4ddb4de54da43a3025","https://git.kernel.org/stable/c/1d84887327659c58a6637060ac8c50c3a952a163","https://git.kernel.org/stable/c/20479886b40c0ed4864a5fc8490a1f6b70cccf1b","https://git.kernel.org/stable/c/4b6641c3a2ba95ddcfecec263b4a5e572a4b0641","https://git.kernel.org/stable/c/992e966caf57e00855edbd79f19d911809732a69","https://git.kernel.org/stable/c/a1cb72e20a64a3c83f9b4ee993fbf97e4c1d7714"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49862 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipc_nl_compat_name_table_dump") where it should have type casted sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative value. syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] | ["https://git.kernel.org/stable/c/082707d3df191bf5bb8801d43e4ce3dea39ca173","https://git.kernel.org/stable/c/1c075b192fe41030457cd4a5f7dea730412bca40","https://git.kernel.org/stable/c/301caa06091af4d5cf056ac8249cbda4e6029c6a","https://git.kernel.org/stable/c/36769b9477491a7af6635863bd950309c1e1b96c","https://git.kernel.org/stable/c/55a253a6753a603e80b95932ca971ba514aa6ce7","https://git.kernel.org/stable/c/6cee2c60bd168279852ac7dbe54c2b70d1028644","https://git.kernel.org/stable/c/a0ead1d648df9c456baec832b494513ef405949a","https://git.kernel.org/stable/c/f31dd158580940938f77514b87337a777520185a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49871 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: tun: Fix memory leaks of napi_get_frags kmemleak reports after running test_progs: unreferenced object 0xffff8881b1672dc0 (size 232): comm "test_progs", pid 394388, jiffies 4354712116 (age 841.975s) hex dump (first 32 bytes): e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff .........,g..... 00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace: [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150 [<0000000041c7fc09>] __napi_build_skb+0x15/0x50 [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540 [<000000003ecfa30e>] napi_get_frags+0x59/0x140 [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun] [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun] [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320 [<000000008f338ea2>] do_iter_write+0x135/0x630 [<000000008a3377a4>] vfs_writev+0x12e/0x440 [<00000000a6b5639a>] do_writev+0x104/0x280 [<00000000ccf065d8>] do_syscall_64+0x3b/0x90 [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: tun_get_user() napi_gro_frags() napi_frags_finish() case GRO_NORMAL: gro_normal_one() list_add_tail(&skb->list, &napi->rx_list); <-- While napi->rx_count < READ_ONCE(gro_normal_batch), <-- gro_normal_list() is not called, napi->rx_list is not empty <-- not ask to complete the gro work, will cause memory leaks in <-- following tun_napi_del() ... tun_napi_del() netif_napi_del() __netif_napi_del() <-- &napi->rx_list is not empty, which caused memory leaks To fix, add napi_complete() after napi_gro_frags(). | ["https://git.kernel.org/stable/c/1118b2049d77ca0b505775fc1a8d1909cf19a7ec","https://git.kernel.org/stable/c/223ef6a94e52331a6a7ef31e59921e0e82d2d40a","https://git.kernel.org/stable/c/3401f964028ac941425b9b2c8ff8a022539ef44a","https://git.kernel.org/stable/c/8b12a020b20a78f62bedc50f26db3bf4fadf8cb9","https://git.kernel.org/stable/c/a4f73f6adc53fd7a3f9771cbc89a03ef39b0b755","https://git.kernel.org/stable/c/d7569302a7a52a9305d2fb054df908ff985553bb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49874 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: hyperv: fix possible memory leak in mousevsc_probe() If hid_add_device() returns error, it should call hid_destroy_device() to free hid_dev which is allocated in hid_allocate_device(). | ["https://git.kernel.org/stable/c/249b743801c00542e9324f87b380032e957a43e8","https://git.kernel.org/stable/c/5ad95d71344b7ffec360d62591633b3c465dc049","https://git.kernel.org/stable/c/5f3aba6566b866f5b0a4916f0b2e8a6ae66a6451","https://git.kernel.org/stable/c/8597b59e3d22b27849bd3e4f92a3d466774bfb04","https://git.kernel.org/stable/c/a6d2fb1874c52ace1f5cf1966ee558829c5c19b6","https://git.kernel.org/stable/c/b5bcb94b0954a026bbd671741fdb00e7141f9c91","https://git.kernel.org/stable/c/e29289d0d8193fca6d2c1f0a1de75cfc80edec00","https://git.kernel.org/stable/c/ed75d1a1c31a0cae8ecc8bcea710b25c0be68da0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49880 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: fix warning in 'ext4_da_release_space' Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): free_blocks=0 EXT4-fs (loop0): dirty_blocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): i_reserved_data_blocks=0 EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wb_workfn (flush-7:0) RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461 mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 do_writepages+0x3c3/0x680 mm/page-writeback.c:2469 __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587 writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044 wb_do_writeback fs/fs-writeback.c:2187 [inline] wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227 process_one_work+0x877/0xdb0 kernel/workqueue.c:2289 worker_thread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Above issue may happens as follows: ext4_da_write_begin ext4_create_inline_data ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS); ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); __ext4_ioctl ext4_ext_migrate -> will lead to eh->eh_entries not zero, and set extent flag ext4_da_write_begin ext4_da_convert_inline_data_to_extent ext4_da_write_inline_data_begin ext4_da_map_blocks ext4_insert_delayed_block if (!ext4_es_scan_clu(inode, &ext4_es_is_delonly, lblk)) if (!ext4_es_scan_clu(inode, &ext4_es_is_mapped, lblk)) ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -> will return 1 allocated = true; ext4_es_insert_delayed_block(inode, lblk, allocated); ext4_writepages mpage_map_and_submit_extent(handle, &mpd, &give_up_on_write); -> return -ENOSPC mpage_release_unused_pages(&mpd, give_up_on_write); -> give_up_on_write == 1 ext4_es_remove_extent ext4_da_release_space(inode, reserved); if (unlikely(to_free > ei->i_reserved_data_blocks)) -> to_free == 1 but ei->i_reserved_data_blocks == 0 -> then trigger warning as above To solve above issue, forbid inode do migrate which has inline data. | ["https://git.kernel.org/stable/c/0a43c015e98121c91a76154edf42280ce1a8a883","https://git.kernel.org/stable/c/0de5ee103747fd3a24f1c010c79caabe35e8f0bb","https://git.kernel.org/stable/c/1b8f787ef547230a3249bcf897221ef0cc78481b","https://git.kernel.org/stable/c/5370b965b7a945bb8f48b9ee23d83a76a947902e","https://git.kernel.org/stable/c/72743d5598b9096950bbfd6a9b7f173d156eea97","https://git.kernel.org/stable/c/890d738f569fa9412b70ba09f15407f17a52da20","https://git.kernel.org/stable/c/89bee03d2fb8c54119b38ac6c24e7d60fae036b6","https://git.kernel.org/stable/c/c3bf1e95cfa7d950dc3c064d0c2e3d06b427bc63"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49881 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: fix memory leak in query_regdb_file() In the function query_regdb_file() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdb_fw_cb(). However, request_firmware_nowait() can fail without calling regdb_fw_cb() and thus leak memory. | ["https://git.kernel.org/stable/c/0ede1a988299e95d54bd89551fd635980572e920","https://git.kernel.org/stable/c/219446396786330937bcd382a7bc4ccd767383bc","https://git.kernel.org/stable/c/38c9fa2cc6bf4b6e1a74057aef8b5cffd23d3264","https://git.kernel.org/stable/c/57b962e627ec0ae53d4d16d7bd1033e27e67677a","https://git.kernel.org/stable/c/e1e12180321f416d83444f2cdc9259e0f5093d35","https://git.kernel.org/stable/c/e9b5a4566d5bc71cc901be50d1fa24da00613120"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49890 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: capabilities: fix potential memleak on error path from vfs_getxattr_alloc() In cap_inode_getsecurity(), we will use vfs_getxattr_alloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic: |-- ret = (int)vfs_getxattr_alloc(mnt_userns, ...) | /* ^^^ alloc for tmpbuf */ |-- value = krealloc(*xattr_value, error + 1, flags) | /* ^^^ alloc memory */ |-- error = handler->get(handler, ...) | /* error! */ |-- *xattr_value = value | /* xattr_value is &tmpbuf (memory leak!) */ So we will try to free(tmpbuf) after vfs_getxattr_alloc() fails to fix it. [PM: subject line and backtrace tweaks] | ["https://git.kernel.org/stable/c/0c3e6288da650d1ec911a259c77bc2d88e498603","https://git.kernel.org/stable/c/2de8eec8afb75792440b8900a01d52b8f6742fd1","https://git.kernel.org/stable/c/6bb00eb21c0fbf18e5d3538c9ff0cf63fd0ace85","https://git.kernel.org/stable/c/7480aeff0093d8c54377553ec6b31110bea37b4d","https://git.kernel.org/stable/c/8cf0a1bc12870d148ae830a4ba88cfdf0e879cee","https://git.kernel.org/stable/c/90577bcc01c4188416a47269f8433f70502abe98","https://git.kernel.org/stable/c/cdf01c807e974048c43c7fd3ca574f6086a57906"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release(). | ["https://git.kernel.org/stable/c/029d5b7688a2f3a86f2a3be5a6ba9cc968c80e41","https://git.kernel.org/stable/c/080aabfb29b2ee9cbb8894a1d039651943d3773e","https://git.kernel.org/stable/c/0d4e91efcaee081e919b3c50e875ecbb84290e41","https://git.kernel.org/stable/c/2ff6b669523d3b3d253a044fa9636a67d0694995","https://git.kernel.org/stable/c/a636fc5a7cabd05699b5692ad838c2c7a3abec7b","https://git.kernel.org/stable/c/d1d1aede313eb2b9a84afd60ff6cfb7c33631e0e","https://git.kernel.org/stable/c/e77d213843e67b4373285712699b692f9c743f61","https://git.kernel.org/stable/c/e7d1d4d9ac0dfa40be4c2c8abd0731659869b297"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49922 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() will only free skb when i2c_master_send() return >=0, which means skb will memleak when i2c_master_send() failed. Free skb no matter whether i2c_master_send() succeeds. | ["https://git.kernel.org/stable/c/52438e734c1566f5e2bcd9a065d2d65e306c0555","https://git.kernel.org/stable/c/5dfdac5e3f8db5f4445228c44f64091045644a3b","https://git.kernel.org/stable/c/825656ae61e73ddc05f585e6258d284c87064b10","https://git.kernel.org/stable/c/92a1df9c6da20c02cf9872f8b025a66ddb307aeb","https://git.kernel.org/stable/c/93d904a734a74c54d945a9884b4962977f1176cd","https://git.kernel.org/stable/c/c8e7d4a1166f063703955f1b2e765a6db5bf1771","https://git.kernel.org/stable/c/dd0ee55ead91fbb16889dbe7ff0b0f7c9e4e849d","https://git.kernel.org/stable/c/f30060efcf18883748a0541aa41acef183cd9c0e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49926 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: dsa: Fix possible memory leaks in dsa_loop_init() kmemleak reported memory leaks in dsa_loop_init(): kmemleak: 12 new suspected memory leaks unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ... There are two reasons for memleak in dsa_loop_init(). First, fixed_phy_register() create and register phy_device: fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove() But fixed_phy_unregister() only calls phy_device_remove(). So the memory allocated in phy_device_create() is leaked. Second, when mdio_driver_register() fail in dsa_loop_init(), it just returns and there is no cleanup for phydevs. Fix the problems by catching the error of mdio_driver_register() in dsa_loop_init(), then calling both fixed_phy_unregister() and phy_device_free() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate. | ["https://git.kernel.org/stable/c/37a098fc9b42bd7fce66764866aa514639667b6e","https://git.kernel.org/stable/c/4d2024b138d9f7b02ae13ee997fd3a71e9e46254","https://git.kernel.org/stable/c/633efc8b3dc96f56f5a57f2a49764853a2fa3f50","https://git.kernel.org/stable/c/935b4beb724946a37cebf97191592d4879d3a3a3","https://git.kernel.org/stable/c/9f555b1584fc2d5d16ee3c4d9438e93ac7c502c7","https://git.kernel.org/stable/c/bbc5d7b46a729bfcbb5544f6612b7a67dd4f4d6f","https://git.kernel.org/stable/c/d593e1ede655b74c42e4e4fe285ea64aee96fb5c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49927 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfs4: Fix kmemleak when allocate slot failed If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak: unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 [<00000000128486db>] nfs4_init_client+0xce/0x270 [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 [<000000005d56bdec>] do_syscall_64+0x35/0x80 [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ["https://git.kernel.org/stable/c/24641993a7dce6b1628645f4e1d97ca06c9f765d","https://git.kernel.org/stable/c/45aea4fbf61e205649c29200726b9f45c1718a67","https://git.kernel.org/stable/c/7e8436728e22181c3f12a5dbabd35ed3a8b8c593","https://git.kernel.org/stable/c/84b5cb476903003ae9ca88f32b57ff0eaefa6d4c","https://git.kernel.org/stable/c/86ce0e93cf6fb4d0c447323ac66577c642628b9d","https://git.kernel.org/stable/c/925cb538bd5851154602818dc80bf4b4d924c127","https://git.kernel.org/stable/c/aae35a0c8a775fa4afa6a4e7dab3f936f1f89bbb","https://git.kernel.org/stable/c/db333ae981fb8843c383aa7dbf62cc682597d401"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52979 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: squashfs: harden sanity check in squashfs_read_xattr_id_table While mounting a corrupted filesystem, a signed integer '*xattr_ids' can become less than zero. This leads to the incorrect computation of 'len' and 'indexes' values which can cause null-ptr-deref in copy_bio_to_actor() or out-of-bounds accesses in the next sanity checks inside squashfs_read_xattr_id_table(). Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/29e774dcb27116c06b9c57b1f1f14a1623738989","https://git.kernel.org/stable/c/72e544b1b28325fe78a4687b980871a7e4101f76","https://git.kernel.org/stable/c/b30a74f83265c24d1d0842c6c3928cd2e775a3fb","https://git.kernel.org/stable/c/b7398efe24a965cf3937b716c0b1011c201c5d6e","https://git.kernel.org/stable/c/cf5d6612092408157db6bb500c70bf6d67c40fbc","https://git.kernel.org/stable/c/db76fc535fbdfbf29fd0b93e49627537ad794c8c","https://git.kernel.org/stable/c/de2785aa3448d1ee7be3ab47fd4a873025f1b3d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52989 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region This patch is fix for Linux kernel v2.6.33 or later. For request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem have had an issue of use-after-free. The subsystem allows multiple user space listeners to the region, while data of the payload was likely released before the listeners execute read(2) to access to it for copying to user space. The issue was fixed by a commit 281e20323ab7 ("firewire: core: fix use-after-free regression in FCP handler"). The object of payload is duplicated in kernel space for each listener. When the listener executes ioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to be released. However, it causes memory leak since the commit relies on call of release_request() in drivers/firewire/core-cdev.c. Against the expectation, the function is never called due to the design of release_client_resource(). The function delegates release task to caller when called with non-NULL fourth argument. The implementation of ioctl_send_response() is the case. It should release the object explicitly. This commit fixes the bug. | ["https://git.kernel.org/stable/c/356ff89acdbe6a66019154bc7eb2d300f5b15103","https://git.kernel.org/stable/c/531390a243ef47448f8bad01c186c2787666bf4d","https://git.kernel.org/stable/c/53785fd9b315583cf029e39f72b73d23704a2253","https://git.kernel.org/stable/c/5f4543c9382ae2d5062f6aa4fecae0c9258d0b0e","https://git.kernel.org/stable/c/b2cd3947d116bb9ba7ff097b5fc747a8956764db","https://git.kernel.org/stable/c/c8bdc88216f09cb7387fedbdf613524367328616","https://git.kernel.org/stable/c/d5a2dcee53fa6e6e2822f93cb3f1b0cd23163bee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53015 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: betop: check shape of output reports betopff_init() only checks the total sum of the report counts for each report field to be at least 4, but hid_betopff_play() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hid_betopff_play(). | ["https://git.kernel.org/stable/c/07bc32e53c7bd5c91472cc485231ef6274db9b76","https://git.kernel.org/stable/c/1a2a47b85cab50a3c146731bfeaf2d860f5344ee","https://git.kernel.org/stable/c/28fc6095da22dc88433d79578ae1c495ebe8ca43","https://git.kernel.org/stable/c/3782c0d6edf658b71354a64d60aa7a296188fc90","https://git.kernel.org/stable/c/7317326f685824c7c29bd80841fd18041af6bb73","https://git.kernel.org/stable/c/d3065cc56221d1a5eda237e94eaf2a627b88ab79","https://git.kernel.org/stable/c/dbab4dba400d6ea9a9697fbbd287adbf7db1dac4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22007 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix error code in chan_alloc_skb_cb() The chan_alloc_skb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference. | ["https://git.kernel.org/stable/c/1bd68db7beb426ab5a45d81516ed9611284affc8","https://git.kernel.org/stable/c/72d061ee630d0dbb45c2920d8d19b3861c413e54","https://git.kernel.org/stable/c/761b7c36addd22c7e6ceb05caaadc3b062d99faa","https://git.kernel.org/stable/c/76304cba8cba12bb10d89d016c28403a2dd89a29","https://git.kernel.org/stable/c/788ae2ae4cf484e248b5bc29211c7ac6510e3e92","https://git.kernel.org/stable/c/a78692ec0d1e17a96b09f2349a028878f5b305e4","https://git.kernel.org/stable/c/b3d607e36fef4bd05fb938a8a868ff70e9fedbe2","https://git.kernel.org/stable/c/ecd06ad0823a90b4420c377ef8917e44e23ee841"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49845 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: j1939: j1939_send_one(): fix missing CAN header initialization The read access to struct canxl_frame::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct can_frame. This patch initializes the 8 byte CAN header with zero. | ["https://git.kernel.org/stable/c/2719f82ad5d8199cf5f346ea8bb3998ad5323b72","https://git.kernel.org/stable/c/3eb3d283e8579a22b81dd2ac3987b77465b2a22f","https://git.kernel.org/stable/c/69e86c6268d59ceddd0abe9ae8f1f5296f316c3c","https://git.kernel.org/stable/c/d0513b095e1ef1469718564dec3fb3348556d0a8","https://git.kernel.org/stable/c/f8e0edeaa0f2b860bdbbf0aafb4492533043d650"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: af_can: fix NULL pointer dereference in can_rx_register() It causes NULL pointer dereference when testing as following: (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket. (b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan link device, and bind vxcan device to bond device (can also use ifenslave command to bind vxcan device to bond device). (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket. (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket. The bond device invokes the can-raw protocol registration interface to receive CAN packets. However, ml_priv is not allocated to the dev, dev_rcv_lists is assigned to NULL in can_rx_register(). In this case, it will occur the NULL pointer dereference issue. The following is the stack information: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:can_rx_register+0x12d/0x1e0 Call Trace: <TASK> raw_enable_filters+0x8d/0x120 raw_enable_allfilters+0x3b/0x130 raw_bind+0x118/0x4f0 __sys_bind+0x163/0x1a0 __x64_sys_bind+0x1e/0x30 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd </TASK> | ["https://git.kernel.org/stable/c/261178a1c2623077d62e374a75c195e6c99a6f05","https://git.kernel.org/stable/c/8aa59e355949442c408408c2d836e561794c40a1","https://git.kernel.org/stable/c/a8055677b054bc2bb78beb1080fdc2dc5158c2fe","https://git.kernel.org/stable/c/afab4655750fcb3fca359bc7d7214e3d634cdf9c","https://git.kernel.org/stable/c/d68fa77ee3d03bad6fe84e89759ddf7005f9e9c6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49869 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix possible crash in bnxt_hwrm_set_coal() During the error recovery sequence, the rtnl_lock is not held for the entire duration and some datastructures may be freed during the sequence. Check for the BNXT_STATE_OPEN flag instead of netif_running() to ensure that the device is fully operational before proceeding to reconfigure the coalescing settings. This will fix a possible crash like this: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 10 PID: 181276 Comm: ethtool Kdump: loaded Tainted: G IOE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/0F9N89, BIOS 2.3.10 08/15/2019 RIP: 0010:bnxt_hwrm_set_coal+0x1fb/0x2a0 [bnxt_en] Code: c2 66 83 4e 22 08 66 89 46 1c e8 10 cb 00 00 41 83 c6 01 44 39 b3 68 01 00 00 0f 8e a3 00 00 00 48 8b 93 c8 00 00 00 49 63 c6 <48> 8b 2c c2 48 8b 85 b8 02 00 00 48 85 c0 74 2e 48 8b 74 24 08 f6 RSP: 0018:ffffb11c8dcaba50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8d168a8b0ac0 RCX: 00000000000000c5 RDX: 0000000000000000 RSI: ffff8d162f72c000 RDI: ffff8d168a8b0b28 RBP: 0000000000000000 R08: b6e1f68a12e9a7eb R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000037 R12: ffff8d168a8b109c R13: ffff8d168a8b10aa R14: 0000000000000000 R15: ffffffffc01ac4e0 FS: 00007f3852e4c740(0000) GS:ffff8d24c0080000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000041b3ee003 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ethnl_set_coalesce+0x3ce/0x4c0 genl_family_rcv_msg_doit.isra.15+0x10f/0x150 genl_family_rcv_msg+0xb3/0x160 ? coalesce_fill_reply+0x480/0x480 genl_rcv_msg+0x47/0x90 ? genl_family_rcv_msg+0x160/0x160 netlink_rcv_skb+0x4c/0x120 genl_rcv+0x24/0x40 netlink_unicast+0x196/0x230 netlink_sendmsg+0x204/0x3d0 sock_sendmsg+0x4c/0x50 __sys_sendto+0xee/0x160 ? syscall_trace_enter+0x1d3/0x2c0 ? __audit_syscall_exit+0x249/0x2a0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7f38524163bb | ["https://git.kernel.org/stable/c/38147073c96dce8c7e142ce0e5f305a420a729ba","https://git.kernel.org/stable/c/6d81ea3765dfa6c8a20822613c81edad1c4a16a0","https://git.kernel.org/stable/c/7781e32984cde65549bedc3201537e253297c98d","https://git.kernel.org/stable/c/a5a05fbef4a0dfe45fe03b2f1d02ba23aebf5384","https://git.kernel.org/stable/c/ac257c43fa615d22180916074feed803b8bb8cb0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49887 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: meson: vdec: fix possible refcount leak in vdec_probe() v4l2_device_unregister need to be called to put the refcount got by v4l2_device_register when vdec_probe fails or vdec_remove is called. | ["https://git.kernel.org/stable/c/0457e7b12ece1a7e41fa0ae8b7e47c0a72a83bef","https://git.kernel.org/stable/c/70119756311a0be3b95bec2e1ba714673e90feba","https://git.kernel.org/stable/c/7718999356234d9cc6a11b4641bb773928f1390f","https://git.kernel.org/stable/c/be6e22f54623d8a856a4f167b25be73c2ff1ff80","https://git.kernel.org/stable/c/f96ad391d054bd5c36994f98afd6a12cbb5600bf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49925 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() KASAN reported a null-ptr-deref error: KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroy_workqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ib_core_cleanup+0xa/0xa1 [ib_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ... It is because the fail of roce_gid_mgmt_init() is ignored: ib_core_init() roce_gid_mgmt_init() gid_cache_wq = alloc_ordered_workqueue # fail ... ib_core_cleanup() roce_gid_mgmt_cleanup() destroy_workqueue(gid_cache_wq) # destroy an unallocated wq Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). | ["https://git.kernel.org/stable/c/07c0d131cc0fe1f3981a42958fc52d573d303d89","https://git.kernel.org/stable/c/6b3d5dcb12347f3518308c2c9d2cf72453a3e1e5","https://git.kernel.org/stable/c/ab817f75e5e0fa58d9be0825da6a7b7d8a1fa1d9","https://git.kernel.org/stable/c/af8fb5a0600e9ae29950e9422a032c3c22649ee5","https://git.kernel.org/stable/c/d360e875c011a005628525bf290322058927e7dc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49931 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Correctly move list in sc_disable() Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") incorrectly tries to move a list from one list head to another. The result is a kernel crash. The crash is triggered when a link goes down and there are waiters for a send to complete. The following signature is seen: BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] Call Trace: sc_disable+0x1ba/0x240 [hfi1] pio_freeze+0x3d/0x60 [hfi1] handle_freeze+0x27/0x1b0 [hfi1] process_one_work+0x1b0/0x380 ? process_one_work+0x380/0x380 worker_thread+0x30/0x360 ? process_one_work+0x380/0x380 kthread+0xd7/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 The fix is to use the correct call to move the list. | ["https://git.kernel.org/stable/c/1afac08b39d85437187bb2a92d89a741b1078f55","https://git.kernel.org/stable/c/25760a41e3802f54aadcc31385543665ab349b8e","https://git.kernel.org/stable/c/7c4260f8f188df32414a5ecad63e8b934c2aa3f0","https://git.kernel.org/stable/c/b8bcff99b07cc175a6ee12a52db51cdd2229586c","https://git.kernel.org/stable/c/ba95409d6b580501ff6d78efd00064f7df669926"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49885 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: APEI: Fix integer overflow in ghes_estatus_pool_init() Change num_ghes from int to unsigned int, preventing an overflow and causing subsequent vmalloc() to fail. The overflow happens in ghes_estatus_pool_init() when calculating len during execution of the statement below as both multiplication operands here are signed int: len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE); The following call trace is observed because of this bug: [ 9.317108] swapper/0: vmalloc error: size 18446744071562596352, exceeds total pages, mode:0xcc0(GFP_KERNEL), nodemask=(null),cpuset=/,mems_allowed=0-1 [ 9.317131] Call Trace: [ 9.317134] <TASK> [ 9.317137] dump_stack_lvl+0x49/0x5f [ 9.317145] dump_stack+0x10/0x12 [ 9.317146] warn_alloc.cold+0x7b/0xdf [ 9.317150] ? __device_attach+0x16a/0x1b0 [ 9.317155] __vmalloc_node_range+0x702/0x740 [ 9.317160] ? device_add+0x17f/0x920 [ 9.317164] ? dev_set_name+0x53/0x70 [ 9.317166] ? platform_device_add+0xf9/0x240 [ 9.317168] __vmalloc_node+0x49/0x50 [ 9.317170] ? ghes_estatus_pool_init+0x43/0xa0 [ 9.317176] vmalloc+0x21/0x30 [ 9.317177] ghes_estatus_pool_init+0x43/0xa0 [ 9.317179] acpi_hest_init+0x129/0x19c [ 9.317185] acpi_init+0x434/0x4a4 [ 9.317188] ? acpi_sleep_proc_init+0x2a/0x2a [ 9.317190] do_one_initcall+0x48/0x200 [ 9.317195] kernel_init_freeable+0x221/0x284 [ 9.317200] ? rest_init+0xe0/0xe0 [ 9.317204] kernel_init+0x1a/0x130 [ 9.317205] ret_from_fork+0x22/0x30 [ 9.317208] </TASK> [ rjw: Subject and changelog edits ] | ["https://git.kernel.org/stable/c/43d2748394c3feb86c0c771466f5847e274fc043","https://git.kernel.org/stable/c/4c10c854113720cbfe75d4f51db79b700a629e73","https://git.kernel.org/stable/c/9edf20e5a1d805855e78f241cf221d741b50d482","https://git.kernel.org/stable/c/c50ec15725e005e9fb20bce69b6c23b135a4a9b7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-22998 | Medium | fixed |
|
In the Linux kernel before 6.0.3, drivers/gpu/drm/virtio/virtgpu_object.c misinterprets the drm_gem_shmem_get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3","https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.0.3","https://github.com/torvalds/linux/commit/c24968734abfed81c8f93dc5f44a7b7a9aecadfa","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49758 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: reset: uniphier-glue: Fix possible null-ptr-deref It will cause null-ptr-deref when resource_size(res) invoked, if platform_get_resource() returns NULL. | ["https://git.kernel.org/stable/c/3a2390c6777e3f6662980c6cfc25cafe9e4fef98","https://git.kernel.org/stable/c/633bad3dc81ce2aa561f704ec091e49eb647bd0b","https://git.kernel.org/stable/c/95de286200b2a046da01c4aeba02ae9220d68ca4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49837 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix memory leaks in __check_func_call kmemleak reports this issue: unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested. In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state(). | ["https://git.kernel.org/stable/c/83946d772e756734a900ef99dbe0aeda506adf37","https://git.kernel.org/stable/c/d4944497827a3d14bc5a26dbcfb7433eb5a956c0","https://git.kernel.org/stable/c/eb86559a691cea5fa63e57a03ec3dc9c31e97955"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49854 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mctp: Fix an error handling path in mctp_init() If mctp_neigh_init() return error, the routes resources should be released in the error handling path. Otherwise some resources leak. | ["https://git.kernel.org/stable/c/216c83222d2eb24b0e63df56e8740b02c33286e8","https://git.kernel.org/stable/c/49d8a6e24a3496d86e8d8ae748375df984fb6d6f","https://git.kernel.org/stable/c/d4072058af4fd8fb4658e7452289042a406a9398"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49855 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfg ipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() to obtain the wwan power state configuration from BIOS but is not freeing the acpi_object. The acpi_evaluate_dsm() returned acpi_object to be freed. Free the acpi_object after use. | ["https://git.kernel.org/stable/c/13b1ea861e8aeb701bcfbfe436b943efa2d44029","https://git.kernel.org/stable/c/7560ceef4d2832a67e8781d924e129c7f542376f","https://git.kernel.org/stable/c/d38a648d2d6cc7bee11c6f533ff9426a00c2a74c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49860 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: k3-udma-glue: fix memory leak when register device fail If device_register() fails, it should call put_device() to give up reference, the name allocated in dev_set_name() can be freed in callback function kobject_cleanup(). | ["https://git.kernel.org/stable/c/025eab5189fc7ee223ae9b4bc49d7df196543e53","https://git.kernel.org/stable/c/1dd27541aa2b95bde71bddd43d73f9c16d73272c","https://git.kernel.org/stable/c/ac2b9f34f02052709aea7b34bb2a165e1853eb41"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49864 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram() ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced. | ["https://git.kernel.org/stable/c/3c1bb6187e566143f15dbf0367ae671584aead5b","https://git.kernel.org/stable/c/5b994354af3cab770bf13386469c5725713679af","https://git.kernel.org/stable/c/613d5a9a440828970f1543b962779401ac2c9c62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49866 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: wwan: mhi: fix memory leak in mhi_mbim_dellink MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice(). | ["https://git.kernel.org/stable/c/2845bc9070cef0c651987487d84d4813d64675dd","https://git.kernel.org/stable/c/3cd3ffe952f78ec5dadf300cb58d4b38a0c0106d","https://git.kernel.org/stable/c/668205b9c9f94d5ed6ab00cce9a46a654c2b5d16"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49867 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: wwan: iosm: fix memory leak in ipc_wwan_dellink IOSM driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch sets needs_free_netdev to true when registers network device, which makes netdev subsystem call free_netdev() automatically after unregister_netdevice(). | ["https://git.kernel.org/stable/c/128514b51a5ba2c82f9e4a106f1c10423907618a","https://git.kernel.org/stable/c/2ce2348c2858d723f7fe389dead9b43b08e0944e","https://git.kernel.org/stable/c/f25caaca424703d5a0607310f0452f978f1f78d9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49878 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, verifier: Fix memory leak in array reallocation for stack state If an error (NULL) is returned by krealloc(), callers of realloc_array() were setting their allocation pointers to NULL, but on error krealloc() does not touch the original allocation. This would result in a memory resource leak. Instead, free the old allocation on the error handling path. The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd | ["https://git.kernel.org/stable/c/06615967d4889b08b19ff3dda96e8b131282f73d","https://git.kernel.org/stable/c/3e210891c4a4c2d858cd6f9f61d5809af251d4df","https://git.kernel.org/stable/c/42378a9ca55347102bbf86708776061d8fe3ece2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: Fix possible memory leak for rq_wb on add_disk failure kmemleak reported memory leaks in device_add_disk(): kmemleak: 3 new suspected memory leaks unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloc_trace+0x26/0x60 [<00000000edc7aadc>] wbt_init+0x50/0x6f0 [<0000000069601d16>] wbt_enable_default+0x157/0x1c0 [<0000000028fc393f>] blk_register_queue+0x2a4/0x420 [<000000007345a042>] device_add_disk+0x6fd/0xe40 [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd] ... It is because the memory allocated in wbt_enable_default() is not released in device_add_disk() error path. Normally, these memory are freed in: del_gendisk() rq_qos_exit() rqos->ops->exit(rqos); wbt_exit() So rq_qos_exit() is called to free the rq_wb memory for wbt_init(). However in the error path of device_add_disk(), only blk_unregister_queue() is called and make rq_wb memory leaked. Add rq_qos_exit() to the error path to fix it. | ["https://git.kernel.org/stable/c/4e68c5da60cd79950bd56287ae80b39d6261f995","https://git.kernel.org/stable/c/528677d3b4af985445bd4ac667485ded1ed11220","https://git.kernel.org/stable/c/fa81cbafbf5764ad5053512152345fab37a1fe18"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49906 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: Free rwi on reset success Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed. | ["https://git.kernel.org/stable/c/535b78739ae75f257c894a05b1afa86ad9a3669e","https://git.kernel.org/stable/c/c3543a287cfba9105dcc4bb41eb817f51266caaf","https://git.kernel.org/stable/c/d6dd2fe71153f0ff748bf188bd4af076fe09a0a6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49908 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix memory leak in vhci_write Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810d81ac00 (size 240): [...] hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418 [<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline] [<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline] [<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline] [<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511 [<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline] [<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline] [<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578 [<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631 [<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================== HCI core will uses hci_rx_work() to process frame, which is queued to the hdev->rx_q tail in hci_recv_frame() by HCI driver. Yet the problem is that, HCI core may not free the skb after handling ACL data packets. To be more specific, when start fragment does not contain the L2CAP length, HCI core just copies skb into conn->rx_skb and finishes frame process in l2cap_recv_acldata(), without freeing the skb, which triggers the above memory leak. This patch solves it by releasing the relative skb, after processing the above case in l2cap_recv_acldata(). | ["https://git.kernel.org/stable/c/5b4f039a2f487c5edae681d763fe1af505f84c13","https://git.kernel.org/stable/c/7c9524d929648935bac2bbb4c20437df8f9c3f42","https://git.kernel.org/stable/c/aa16cac06b752e5f609c106735bd7838f444784c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49928 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed There is a null-ptr-deref when xps sysfs alloc failed: BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0 Read of size 8 at addr 0000000000000030 by task gssproxy/457 CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9 Call Trace: <TASK> dump_stack_lvl+0x34/0x44 kasan_report+0xa3/0x120 sysfs_do_create_link_sd+0x40/0xd0 rpc_sysfs_client_setup+0x161/0x1b0 rpc_new_client+0x3fc/0x6e0 rpc_create_xprt+0x71/0x220 rpc_create+0x1d4/0x350 gssp_rpc_create+0xc3/0x160 set_gssp_clnt+0xbc/0x140 write_gssp+0x116/0x1a0 proc_reg_write+0xd6/0x130 vfs_write+0x177/0x690 ksys_write+0xb9/0x150 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 When the xprt_switch sysfs alloc failed, should not add xprt and switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize the 'xps_sysfs' to NULL to avoid oops when destroy it. | ["https://git.kernel.org/stable/c/7b189b0aa8dab14b49c31c65af8a982e96e25b62","https://git.kernel.org/stable/c/cbdeaee94a415800c65a8c3fa04d9664a8b8fb3a","https://git.kernel.org/stable/c/d59722d088a9d86ce6d9d39979e5d1d669d249f7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52978 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: riscv: kprobe: Fixup kernel panic when probing an illegal position The kernel would panic when probed for an illegal position. eg: (CONFIG_RISCV_ISA_C=n) echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_events echo 1 > events/kprobes/hello/enable cat trace Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 CPU: 0 PID: 111 Comm: sh Not tainted 6.2.0-rc1-00027-g2d398fe49a4d #490 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff80007268>] dump_backtrace+0x38/0x48 [<ffffffff80c5e83c>] show_stack+0x50/0x68 [<ffffffff80c6da28>] dump_stack_lvl+0x60/0x84 [<ffffffff80c6da6c>] dump_stack+0x20/0x30 [<ffffffff80c5ecf4>] panic+0x160/0x374 [<ffffffff80c6db94>] generic_handle_arch_irq+0x0/0xa8 [<ffffffff802deeb0>] sys_newstat+0x0/0x30 [<ffffffff800158c0>] sys_clone+0x20/0x30 [<ffffffff800039e8>] ret_from_syscall+0x0/0x4 ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]--- That is because the kprobe's ebreak instruction broke the kernel's original code. The user should guarantee the correction of the probe position, but it couldn't make the kernel panic. This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent an illegal position (Such as the middle of an instruction). | ["https://git.kernel.org/stable/c/04a73558209554da17f46490ec4faaaf1b2bab68","https://git.kernel.org/stable/c/12316538b1d193064109ce1a28fc9bacd43950de","https://git.kernel.org/stable/c/87f48c7ccc73afc78630530d9af51f458f58cab8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53011 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: enable all safety features by default In the original implementation of dwmac5 commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features") all safety features were enabled by default. Later it seems some implementations didn't have support for all the features, so in commit 5ac712dcdfef ("net: stmmac: enable platform specific safety features") the safety_feat_cfg structure was added to the callback and defined for some platforms to selectively enable these safety features. The problem is that only certain platforms were given that software support. If the automotive safety package bit is set in the hardware features register the safety feature callback is called for the platform, and for platforms that didn't get a safety_feat_cfg defined this results in the following NULL pointer dereference: [ 7.933303] Call trace: [ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac] [ 7.941455] __stmmac_open+0x16c/0x474 [stmmac] [ 7.946117] stmmac_open+0x38/0x70 [stmmac] [ 7.950414] __dev_open+0x100/0x1dc [ 7.954006] __dev_change_flags+0x18c/0x204 [ 7.958297] dev_change_flags+0x24/0x6c [ 7.962237] do_setlink+0x2b8/0xfa4 [ 7.965827] __rtnl_newlink+0x4ec/0x840 [ 7.969766] rtnl_newlink+0x50/0x80 [ 7.973353] rtnetlink_rcv_msg+0x12c/0x374 [ 7.977557] netlink_rcv_skb+0x5c/0x130 [ 7.981500] rtnetlink_rcv+0x18/0x2c [ 7.985172] netlink_unicast+0x2e8/0x340 [ 7.989197] netlink_sendmsg+0x1a8/0x420 [ 7.993222] ____sys_sendmsg+0x218/0x280 [ 7.997249] ___sys_sendmsg+0xac/0x100 [ 8.001103] __sys_sendmsg+0x84/0xe0 [ 8.004776] __arm64_sys_sendmsg+0x24/0x30 [ 8.008983] invoke_syscall+0x48/0x114 [ 8.012840] el0_svc_common.constprop.0+0xcc/0xec [ 8.017665] do_el0_svc+0x38/0xb0 [ 8.021071] el0_svc+0x2c/0x84 [ 8.024212] el0t_64_sync_handler+0xf4/0x120 [ 8.028598] el0t_64_sync+0x190/0x194 Go back to the original behavior, if the automotive safety package is found to be supported in hardware enable all the features unless safety_feat_cfg is passed in saying this particular platform only supports a subset of the features. | ["https://git.kernel.org/stable/c/120b8e527e07c65de7f2b9018dcd9d17e66f2427","https://git.kernel.org/stable/c/aebf7e62708ba706ee7bf484c9023b15c214e92a","https://git.kernel.org/stable/c/fdfc76a116b5e9d3e98e6c96fe83b42d011d21d4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49839 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_sas: Fix error handling in sas_phy_add() If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add(). | ["https://git.kernel.org/stable/c/03aabcb88aeeb7221ddb6196ae84ad5fb17b743f","https://git.kernel.org/stable/c/2f21d653c648735657e23948b1d7ac7273de0f87","https://git.kernel.org/stable/c/5d7bebf2dfb0dc97aac1fbace0910e557ecdb16f","https://git.kernel.org/stable/c/c736876ee294bb4f271d76a25cc7d70c8537bc5d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init() When prestera_sdma_switch_init() failed, the memory pointed to by sw->rxtx isn't released. Fix it. Only be compiled, not be tested. | ["https://git.kernel.org/stable/c/31e5084ac6876e52dbb0a1cc4fc18b6c79979f31","https://git.kernel.org/stable/c/409731df6310a33f4d0a3ef594d2410cdcd637f2","https://git.kernel.org/stable/c/519b58bbfa825f042fcf80261cc18e1e35f85ffd","https://git.kernel.org/stable/c/5333cf1b7f6861912aff6263978d4781f9858e47"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49873 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix wrong reg type conversion in release_reference() Some helper functions will allocate memory. To avoid memory leaks, the verifier requires the eBPF program to release these memories by calling the corresponding helper functions. When a resource is released, all pointer registers corresponding to the resource should be invalidated. The verifier use release_references() to do this job, by apply __mark_reg_unknown() to each relevant register. It will give these registers the type of SCALAR_VALUE. A register that will contain a pointer value at runtime, but of type SCALAR_VALUE, which may allow the unprivileged user to get a kernel pointer by storing this register into a map. Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this problem. | ["https://git.kernel.org/stable/c/466ce46f251dfb259a8cbaa895ab9edd6fb56240","https://git.kernel.org/stable/c/ae5ccad6c711db0f2ca1231be051935dd128b8f5","https://git.kernel.org/stable/c/cedd4f01f67be94735f15123158f485028571037","https://git.kernel.org/stable/c/f1db20814af532f85e091231223e5e4818e8464b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE When using bpftool to pin {PROG, MAP, LINK} without FILE, segmentation fault will occur. The reson is that the lack of FILE will cause strlen to trigger NULL pointer dereference. The corresponding stacktrace is shown below: do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereference Fix it by adding validation to the common process. | ["https://git.kernel.org/stable/c/34de8e6e0e1f66e431abf4123934a2581cb5f133","https://git.kernel.org/stable/c/6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a","https://git.kernel.org/stable/c/8c80b2fca4112d724dde477aed13f7b0510a2792","https://git.kernel.org/stable/c/da5161ba94c5e9182c301dd4f09c94f715c068bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49891 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: kprobe: Fix memory leak in test_gen_kprobe/kretprobe_cmd() test_gen_kprobe_cmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in test_gen_kretprobe_cmd(). unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/gen_kp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robe_test do_sys backtrace: [<000000006d7b836b>] kmalloc_trace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] do_one_initcall+0x87/0x2a0 [<00000000c4980a7e>] do_init_module+0xdf/0x320 [<00000000d775aad0>] load_module+0x3006/0x3390 [<00000000e9a74b80>] __do_sys_finit_module+0x113/0x1b0 [<000000003726480d>] do_syscall_64+0x35/0x80 [<000000003441e93b>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 | ["https://git.kernel.org/stable/c/66f0919c953ef7b55e5ab94389a013da2ce80a2c","https://git.kernel.org/stable/c/71aeb8d01a8c7ab5cf7da3f81b35206f56ce6bca","https://git.kernel.org/stable/c/bef08acbe560a926b4cee9cc46404cc98ae5703b","https://git.kernel.org/stable/c/d1b6a8e3414aeaa0985139180c145d2d0fbd2a49"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49923 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the result, the skb will memleak. nxp_nci_send() should also free the skb when nxp_nci_i2c_write() succeeds. | ["https://git.kernel.org/stable/c/3cba1f061bfe23fece2841129ca2862cdec29d5c","https://git.kernel.org/stable/c/3ecf0f4227029b2c42e036b10ff6e5d09e20821e","https://git.kernel.org/stable/c/7bf1ed6aff0f70434bd0cdd45495e83f1dffb551","https://git.kernel.org/stable/c/9ae2c9a91ff068f4c3e392f47e8e26a1c9f85ebb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49924 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: fdp: Fix potential memory leak in fdp_nci_send() fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in the function. As a result, when fdp_nci_i2c_write() finished, the skb will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() finished. | ["https://git.kernel.org/stable/c/1a7a898f8f7b56c0eaa2baf67a0c96235a30bc29","https://git.kernel.org/stable/c/44bc1868a4f542502ea2221fe5ad88ca66d1c6b6","https://git.kernel.org/stable/c/8e4aae6b8ca76afb1fb64dcb24be44ba814e7f8a","https://git.kernel.org/stable/c/e8c11ee2d07f7c4dfa2ac0ea8efc4f627e58ea57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52991 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: fix NULL pointer in skb_segment_list Commit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.") introduced UDP listifyed GRO. The segmentation relies on frag_list being untouched when passing through the network stack. This assumption can be broken sometimes, where frag_list itself gets pulled into linear area, leaving frag_list being NULL. When this happens it can trigger following NULL pointer dereference, and panic the kernel. Reverse the test condition should fix it. [19185.577801][ C1] BUG: kernel NULL pointer dereference, address: ... [19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390 ... [19185.834644][ C1] Call Trace: [19185.841730][ C1] <TASK> [19185.848563][ C1] __udp_gso_segment+0x33e/0x510 [19185.857370][ C1] inet_gso_segment+0x15b/0x3e0 [19185.866059][ C1] skb_mac_gso_segment+0x97/0x110 [19185.874939][ C1] __skb_gso_segment+0xb2/0x160 [19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0 [19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90 [19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200 [19185.910003][ C1] ip_local_deliver_finish+0x44/0x60 [19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0 [19185.927834][ C1] process_backlog+0x88/0x130 [19185.935840][ C1] __napi_poll+0x27/0x150 [19185.943447][ C1] net_rx_action+0x27e/0x5f0 [19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core] [19185.960848][ C1] __do_softirq+0xbc/0x25d [19185.968607][ C1] irq_exit_rcu+0x83/0xb0 [19185.976247][ C1] common_interrupt+0x43/0xa0 [19185.984235][ C1] asm_common_interrupt+0x22/0x40 ... [19186.094106][ C1] </TASK> | ["https://git.kernel.org/stable/c/046de74f9af92ae9ffce75fa22a1795223f4fb54","https://git.kernel.org/stable/c/6446369fb9f083ce032448c5047da08e298b22e6","https://git.kernel.org/stable/c/876e8ca8366735a604bac86ff7e2732fc9d85d2d","https://git.kernel.org/stable/c/888dad6f3e85e3b2f8389bd6478f181efc72534d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22037 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix null pointer dereference in alloc_preauth_hash() The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete. | ["https://git.kernel.org/stable/c/8f216b33a5e1b3489c073b1ea1b3d7cb63c8dc4d","https://git.kernel.org/stable/c/b8eb243e670ecf30e91524dd12f7260dac07d335","https://git.kernel.org/stable/c/c8b5b7c5da7d0c31c9b7190b4a7bba5281fc4780","https://git.kernel.org/stable/c/ca8bed31edf728a662ef9d6f39f50e7a7dc2b5ad"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23455 | Medium | N/A | atm_tc_enqueue in net/sched/sch_atm.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results). | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a2965c7be0522eaa18808684b7b82b248515511b","https://lists.debian.org/debian-lts-announce/2023/03/msg00000.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.debian.org/security/2023/dsa-5324","https://www.openwall.com/lists/oss-security/2023/01/10/1","https://www.openwall.com/lists/oss-security/2023/01/10/4"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3567 | Medium | N/A | A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function inet6_stream_ops/inet6_dgram_ops of the component IPv6 Handler. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211090 is the identifier assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=364f997b5cfe1db0d63a390fe7c801fa2b3115f6","https://vuldb.com/?id.211090","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=364f997b5cfe1db0d63a390fe7c801fa2b3115f6","https://vuldb.com/?id.211090"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0469 | Medium | fixed |
|
A use-after-free flaw was found in io_uring/filetable.c in io_install_fixed_file in the io_uring subcomponent in the Linux Kernel during call cleanup. This flaw may lead to a denial of service. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2163723","https://bugzilla.redhat.com/show_bug.cgi?id=2163723"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-34256 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 6.3.3. There is an out-of-bounds read in crc16 in lib/crc16.c when called from fs/ext4/super.c because ext4_group_desc_csum does not properly check an offset. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated "When modifying the block device while it is mounted by the filesystem" access. | ["https://bugzilla.suse.com/show_bug.cgi?id=1211895","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321","https://bugzilla.suse.com/show_bug.cgi?id=1211895","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4f04351888a83e595571de672e0a4a8b74f4fb31","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://syzkaller.appspot.com/bug?extid=8785e41224a3afd04321"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-22996 | Medium | fixed |
|
In the Linux kernel before 5.17.2, drivers/soc/qcom/qcom_aoss.c does not release an of_find_device_by_node reference after use, e.g., with put_device. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://github.com/torvalds/linux/commit/4b41a9d0fe3db5f91078a380f62f0572c3ecf2dd","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.2","https://github.com/torvalds/linux/commit/4b41a9d0fe3db5f91078a380f62f0572c3ecf2dd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-22999 | Medium | fixed |
|
In the Linux kernel before 5.16.3, drivers/usb/dwc3/dwc3-qcom.c misinterprets the dwc3_qcom_create_urs_usb_platdev return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/b52fe2dbb3e655eb1483000adfab68a219549e13","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/b52fe2dbb3e655eb1483000adfab68a219549e13"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49750 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cpufreq: CPPC: Add u64 casts to avoid overflowing The fields of the _CPC object are unsigned 32-bits values. To avoid overflows while using _CPC's values, add 'u64' casts. | ["https://git.kernel.org/stable/c/7d596bbc66a52ff2c7a83d7e0ee840cb07e2a045","https://git.kernel.org/stable/c/f5f94b9c8b805d87ff185caf9779c3a4d07819e3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53002 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix a memory leak with reused mmap_offset drm_vma_node_allow() and drm_vma_node_revoke() should be called in balanced pairs. We call drm_vma_node_allow() once per-file everytime a user calls mmap_offset, but only call drm_vma_node_revoke once per-file on each mmap_offset. As the mmap_offset is reused by the client, the per-file vm_count may remain non-zero and the rbtree leaked. Call drm_vma_node_allow_once() instead to prevent that memory leak. | ["https://git.kernel.org/stable/c/0220e4fe178c3390eb0291cdb34912d66972db8a","https://git.kernel.org/stable/c/0bdc4b4ba7206c452ee81c82fa66e39d0e1780fb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49300 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between nbd_alloc_config() and module removal When nbd module is being removing, nbd_alloc_config() may be called concurrently by nbd_genl_connect(), although try_module_get() will return false, but nbd_alloc_config() doesn't handle it. The race may lead to the leak of nbd_config and its related resources (e.g, recv_workq) and oops in nbd_read_stat() due to the unload of nbd module as shown below: BUG: kernel NULL pointer dereference, address: 0000000000000040 Oops: 0000 [#1] SMP PTI CPU: 5 PID: 13840 Comm: kworker/u17:33 Not tainted 5.14.0+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: knbd16-recv recv_work [nbd] RIP: 0010:nbd_read_stat.cold+0x130/0x1a4 [nbd] Call Trace: recv_work+0x3b/0xb0 [nbd] process_one_work+0x1ed/0x390 worker_thread+0x4a/0x3d0 kthread+0x12a/0x150 ret_from_fork+0x22/0x30 Fixing it by checking the return value of try_module_get() in nbd_alloc_config(). As nbd_alloc_config() may return ERR_PTR(-ENODEV), assign nbd->config only when nbd_alloc_config() succeeds to ensure the value of nbd->config is binary (valid or NULL). Also adding a debug message to check the reference counter of nbd_config during module removal. | ["https://git.kernel.org/stable/c/122e4adaff2439f1cc18cc7e931980fa7560df5c","https://git.kernel.org/stable/c/165cf2e0019fa6cedc75b456490c41494c34abb4","https://git.kernel.org/stable/c/2573f2375b64280be977431701ed5d33b75b9ad0","https://git.kernel.org/stable/c/2888fa41985f93ed0a6837cfbb06bcbfd7fa2314","https://git.kernel.org/stable/c/71c142f910da44421213ade601bcbd23ceae19fa","https://git.kernel.org/stable/c/8a7da4ced236ce6637fe70f14ca18e718d4bf9e9","https://git.kernel.org/stable/c/c55b2b983b0fa012942c3eb16384b2b722caa810","https://git.kernel.org/stable/c/d09525720dd5201756f698bee1076de9aefd4602"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49344 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'s lock held and check if its receive queue is full. Here we need to use unix_recvq_full_lockless() instead of unix_recvq_full(), otherwise KCSAN will report a data-race. | ["https://git.kernel.org/stable/c/556720013c36c193d9cbfb06e7b33e51f0c39fbf","https://git.kernel.org/stable/c/662a80946ce13633ae90a55379f1346c10f0c432","https://git.kernel.org/stable/c/71e8bfc7f838cabc60cba24e09ca84c4f8321ab2","https://git.kernel.org/stable/c/8801eb3ccd2e4e3b1a01449383e3321ae6dbd9d6","https://git.kernel.org/stable/c/95f0ba806277733bf6024e23e27e1be773701cca","https://git.kernel.org/stable/c/c61848500a3fd6867dfa4834b8c7f97133eceb9f","https://git.kernel.org/stable/c/c926ae58f24f7bd55aa2ea4add9f952032507913"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49571 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_max_reordering. While reading sysctl_tcp_max_reordering, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/064852663308c801861bd54789d81421fa4c2928","https://git.kernel.org/stable/c/46deb91ac8a790286ad6d24cf92e7ab0ab2582bb","https://git.kernel.org/stable/c/50a1d3d097503a90cf84ebe120afcde37e9c33b3","https://git.kernel.org/stable/c/5e38cee24f19d19280c68f1ac8bf6790d607f60a","https://git.kernel.org/stable/c/a11e5b3e7a59fde1a90b0eaeaa82320495cf8cae","https://git.kernel.org/stable/c/ce3731c61589ed73364a5b55ce34131762ef9b60"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49573 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_early_retrans. While reading sysctl_tcp_early_retrans, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/11e8b013d16e5db63f8f76acceb5b86964098aaa","https://git.kernel.org/stable/c/488d3ad98ef7cddce7054193dbae6b4349c6807d","https://git.kernel.org/stable/c/5037ca9e4b169cc9aed0174d658c3d81fdaf8ea5","https://git.kernel.org/stable/c/52e65865deb6a36718a463030500f16530eaab74","https://git.kernel.org/stable/c/83767fe800a311370330d4ec83aa76093b744a80","https://git.kernel.org/stable/c/d5975f6376ce90c2c483ae36bf88c9cface4c13b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49574 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_recovery. While reading sysctl_tcp_recovery, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/52ee7f5c4811ce6be1becd14d38ba1f8a8a0df81","https://git.kernel.org/stable/c/92c35113c63306091df9211375eebd0abd8c2160","https://git.kernel.org/stable/c/a31e2d0cb5cfa2aae3144cac04f25031d5d20fb4","https://git.kernel.org/stable/c/c7a492db1f7c37c758a66915908677bd8bc5d368","https://git.kernel.org/stable/c/d8781f7cd04091744f474a2bada74772084b9dc9","https://git.kernel.org/stable/c/e7d2ef837e14a971a05f60ea08c47f3fed1a36e4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49575 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_thin_linear_timeouts. While reading sysctl_tcp_thin_linear_timeouts, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/404c53ccdebd11f96954f4070cffac8e0b4d5cb6","https://git.kernel.org/stable/c/492f3713b282c0e67e951cd804edd22eccc25412","https://git.kernel.org/stable/c/7c6f2a86ca590d5187a073d987e9599985fb1c7c","https://git.kernel.org/stable/c/a0f96c4f179cb3560078cefccef105e8f1701210","https://git.kernel.org/stable/c/cc133e4f4bc225079198192623945bb872c08143","https://git.kernel.org/stable/c/f4b0295be9a3c4260de4585fac4062e602a88ac7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49586 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen. While reading sysctl_tcp_fastopen, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/03da610696a32578fc4f986479341ce9d430df08","https://git.kernel.org/stable/c/22938534c611136f35e2ca545bb668073ca5ef49","https://git.kernel.org/stable/c/25d53d858a6c0b89a6e69e376c2a57c4f4c2c8cc","https://git.kernel.org/stable/c/448ab998947996a0a451f8229f19087964cf2670","https://git.kernel.org/stable/c/539d9ab79eba3974b479cad61a8688c41fe62e12","https://git.kernel.org/stable/c/5a54213318c43f4009ae158347aa6016e3b9b55a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49587 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_notsent_lowat. While reading sysctl_tcp_notsent_lowat, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/0f75343584ee474303e17efe0610bdd170af1d13","https://git.kernel.org/stable/c/55be873695ed8912eb77ff46d1d1cadf028bd0f3","https://git.kernel.org/stable/c/62e56cfeb2ae4b53ae9ca24c80f54093250ce64a","https://git.kernel.org/stable/c/80d4d0c461674eea87f0977e12a2ecd334b9b79c","https://git.kernel.org/stable/c/91e21df688f8a75255ca9c459da39ac96300113a","https://git.kernel.org/stable/c/c1b85c5a34294f7444c13bf828e0e84b0a0eed85","https://git.kernel.org/stable/c/e9362a993886613ef0284c2a4911c6017c97d803","https://git.kernel.org/stable/c/fd6f1284e380c377932186042ff0b5c987fb2b92"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49593 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_probe_interval. While reading sysctl_tcp_probe_interval, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/2a85388f1d94a9f8b5a529118a2c5eaa0520d85c","https://git.kernel.org/stable/c/73a11588751a2c13f25d9da8117efc9a79b1843f","https://git.kernel.org/stable/c/80dabd089086e6553b7acfcff2ec223bdada87a1","https://git.kernel.org/stable/c/b14cc8afbbcbc6dce4797913c0b85266b897f541","https://git.kernel.org/stable/c/b3798d3519eda9c409bb0815b0102f27ec42468d","https://git.kernel.org/stable/c/c61aede097d350d890fa1edc9521b0072e14a0b8","https://git.kernel.org/stable/c/e6b6f027e2854a51f345a5e3e808d7a88001d4f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49598 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_mtu_probing. While reading sysctl_tcp_mtu_probing, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/77a04845f0d28a3561494a5f3121488470a968a4","https://git.kernel.org/stable/c/7e8fc428a7f680f1c4994a40e52d7f95a9a93038","https://git.kernel.org/stable/c/aabe9438fdfe004e021d5a206227ec105dbe2416","https://git.kernel.org/stable/c/b0920ca09d9ce19980c8391b9002455baa9c1417","https://git.kernel.org/stable/c/f47d00e077e7d61baf69e46dde3210c886360207","https://git.kernel.org/stable/c/f966773e13cdd3f12baa90071b7b660f6c633ccb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49601 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp/dccp: Fix a data-race around sysctl_tcp_fwmark_accept. While reading sysctl_tcp_fwmark_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/13207f9485b5de68decf296ceb0046f5eabb2485","https://git.kernel.org/stable/c/1a0008f9df59451d0a17806c1ee1a19857032fa8","https://git.kernel.org/stable/c/45fc82706a97242539d6b841ddd7a077ec20757b","https://git.kernel.org/stable/c/526d8cf8824f613c72dba2155542295e70135f62","https://git.kernel.org/stable/c/a7386602a2fe2f6192477e8ede291a815da09d81","https://git.kernel.org/stable/c/abf70de2ec026ae8d7da4e79bec61888a880e00b","https://git.kernel.org/stable/c/bf3134feffe61b7a0e21f60a04743f8da0958b53","https://git.kernel.org/stable/c/d4f65615db7fca3df9f7e79eadf937e6ddb03c54"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49602 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip: Fix a data-race around sysctl_fwmark_reflect. While reading sysctl_fwmark_reflect, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/0ee76fe01ff3c0b4efaa500aecc90d7c8d3a8860","https://git.kernel.org/stable/c/25a635a67c830766110410fea88ec4e6ee29684b","https://git.kernel.org/stable/c/5e7a1be3e68deef250ad43cc91f7bb8d7d758b48","https://git.kernel.org/stable/c/85d0b4dbd74b95cc492b1f4e34497d3f894f5d9a","https://git.kernel.org/stable/c/9096edcf4854289f92252e086cf6e498c7f8c21d","https://git.kernel.org/stable/c/a475ecc9ad919aa3ebdd4e4a6ee612b793bf74b3","https://git.kernel.org/stable/c/dccf8a67f30e18980d13f07006e5a536bbd1e136","https://git.kernel.org/stable/c/fc92e3b4bebfdd986ef1d2c5019f236837b0b982"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49604 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_fwd_use_pmtu. While reading sysctl_ip_fwd_use_pmtu, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/60c158dc7b1f0558f6cadd5b50d0386da0000d50","https://git.kernel.org/stable/c/7828309df0f89419a9349761a37c7d1b0da45697","https://git.kernel.org/stable/c/93fbc06da1d819f3981a7bd7928c3641ea67b364","https://git.kernel.org/stable/c/b96ed5ccb09ae71103023ed13acefb194f609794","https://git.kernel.org/stable/c/e364b5f6ffbfc457a997ad09a7baa16c19581edc","https://git.kernel.org/stable/c/eb15262128b793e4b1d1c4514d3e6d19c3959764"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49607 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix data race between perf_event_set_output() and perf_mmap_close() Yang Jihing reported a race between perf_event_set_output() and perf_mmap_close(): CPU1 CPU2 perf_mmap_close(e2) if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0 detach_rest = true ioctl(e1, IOC_SET_OUTPUT, e2) perf_event_set_output(e1, e2) ... list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry) ring_buffer_attach(e, NULL); // e1 isn't yet added and // therefore not detached ring_buffer_attach(e1, e2->rb) list_add_rcu(&e1->rb_entry, &e2->rb->event_list) After this; e1 is attached to an unmapped rb and a subsequent perf_mmap() will loop forever more: again: mutex_lock(&e->mmap_mutex); if (event->rb) { ... if (!atomic_inc_not_zero(&e->rb->mmap_count)) { ... mutex_unlock(&e->mmap_mutex); goto again; } } The loop in perf_mmap_close() holds e2->mmap_mutex, while the attach in perf_event_set_output() holds e1->mmap_mutex. As such there is no serialization to avoid this race. Change perf_event_set_output() to take both e1->mmap_mutex and e2->mmap_mutex to alleviate that problem. Additionally, have the loop in perf_mmap() detach the rb directly, this avoids having to wait for the concurrent perf_mmap_close() to get around to doing it to make progress. | ["https://git.kernel.org/stable/c/17f5417194136517ee9bbd6511249e5310e5617c","https://git.kernel.org/stable/c/3bbd868099287ff9027db59029b502fcfa2202a0","https://git.kernel.org/stable/c/43128b3eee337824158f34da6648163d2f2fb937","https://git.kernel.org/stable/c/68e3c69803dada336893640110cb87221bb01dcf","https://git.kernel.org/stable/c/98c3c8fd0d4c560e0f8335b79c407bbf7fc9462c","https://git.kernel.org/stable/c/a9391ff7a7c5f113d6f2bf6621d49110950de49c","https://git.kernel.org/stable/c/da3c256e2d0ebc87c7db0c605c9692b6f1722074","https://git.kernel.org/stable/c/f836f9ac95df15f1e0af4beb0ec20021e8c91998"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49638 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl. While reading icmp sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races. | ["https://git.kernel.org/stable/c/0cba7ca667ceb06934746ddd9833a25847bde81d","https://git.kernel.org/stable/c/1740e5922fbb705637ae9fa5203db132fc45f9f6","https://git.kernel.org/stable/c/48d7ee321ea5182c6a70782aa186422a70e67e22","https://git.kernel.org/stable/c/53ecd09ef2fb35fa69667ae8e414ef6b00fd3bf6","https://git.kernel.org/stable/c/798c2cf57c63ab39c8aac24d6a3d50f4fa5eeb06","https://git.kernel.org/stable/c/e088ceb73c24ab4774da391d54a6426f4bfaefce","https://git.kernel.org/stable/c/e2828e8c605853f71267825c9415437c0a93e4f2","https://git.kernel.org/stable/c/edeec63b13c252193d626c2a48d7a2f0e7016dc2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49639 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: cipso: Fix data-races around sysctl. While reading cipso sysctl variables, they can be changed concurrently. So, we need to add READ_ONCE() to avoid data-races. | ["https://git.kernel.org/stable/c/07b0caf8aeb9b82e6ecc6c292a3e47c7fcdb1148","https://git.kernel.org/stable/c/0e41a0f73ccb9be112a80bde3804a771633caaef","https://git.kernel.org/stable/c/2764f82bbc158d106693ae3ced3675cf4b963b35","https://git.kernel.org/stable/c/59e26906b89cc35bb54476498772b45cbc32323f","https://git.kernel.org/stable/c/c321e99d2725d11f7e6a4ebd9ce752259f0bae81","https://git.kernel.org/stable/c/ca26ca5e2f3eeb3e6fe699cd6effa3b4b2aa8698","https://git.kernel.org/stable/c/dd44f04b9214adb68ef5684ae87a81ba03632250","https://git.kernel.org/stable/c/fe2a35fa2c4f9c8ce5ef970eb927031387f9446a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49596 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_min_snd_mss. While reading sysctl_tcp_min_snd_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/0d8a39feb58910a7f7746b1770ee5578cc551fe6","https://git.kernel.org/stable/c/0fc9357282df055e30990b29f4b7afa53ab42cdb","https://git.kernel.org/stable/c/78eb166cdefcc3221c8c7c1e2d514e91a2eb5014","https://git.kernel.org/stable/c/97992e8feff33b3ae154a113ec398546bbacda80","https://git.kernel.org/stable/c/fdb96b69f5909ffcdd6f1e0902219fc6d7689ff7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49597 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_base_mss. While reading sysctl_tcp_base_mss, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/30b73edc1d2459ba2c71cb58fbf84a1a6e640fbf","https://git.kernel.org/stable/c/4d7dea651b7fe0322be95054f64e3711afccc543","https://git.kernel.org/stable/c/514d2254c7b8aa2d257f5ffc79f0d96be2d6bfda","https://git.kernel.org/stable/c/88d78bc097cd8ebc6541e93316c9d9bf651b13e8","https://git.kernel.org/stable/c/9ca18116bc16ec31b9a3ce28ea1350badfa36128"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49631 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: raw: Fix a data-race around sysctl_raw_l3mdev_accept. While reading sysctl_raw_l3mdev_accept, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/038a87b3e460d2ee579c8b1bd3890d816d6687b1","https://git.kernel.org/stable/c/1dace014928e6e385363032d359a04dee9158af0","https://git.kernel.org/stable/c/46e9c46203fd4676720ddca0fef7eff26826648e","https://git.kernel.org/stable/c/ab5adca2e17d6595f3fc0e25ccb6bcbe2e01ca4f","https://git.kernel.org/stable/c/cc9540ba5b3652c473af7e54892a48cdced87983"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49637 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix a data-race around sysctl_fib_sync_mem. While reading sysctl_fib_sync_mem, it can be changed concurrently. So, we need to add READ_ONCE() to avoid a data-race. | ["https://git.kernel.org/stable/c/190cd4ff128373271e065afb20f1d2247b3f10c3","https://git.kernel.org/stable/c/418b191d5f223a8cb6cab09eae1f72c04ba6adf2","https://git.kernel.org/stable/c/73318c4b7dbd0e781aaababff17376b2894745c0","https://git.kernel.org/stable/c/7c1acd98fb221dc0d847451b9ab86319f8b9916c","https://git.kernel.org/stable/c/9be8aac91960ea32fd0e874758c9afee665c57d2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49733 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: oss: Fix race at SNDCTL_DSP_SYNC There is a small race window at snd_pcm_oss_sync() that is called from OSS PCM SNDCTL_DSP_SYNC ioctl; namely the function calls snd_pcm_oss_make_ready() at first, then takes the params_lock mutex for the rest. When the stream is set up again by another thread between them, it leads to inconsistency, and may result in unexpected results such as NULL dereference of OSS buffer as a fuzzer spotted recently. The fix is simply to cover snd_pcm_oss_make_ready() call into the same params_lock mutex with snd_pcm_oss_make_ready_locked() variant. | ["https://git.kernel.org/stable/c/4051324a6dafd7053c74c475e80b3ba10ae672b0","https://git.kernel.org/stable/c/723ac5ab2891b6c10dd6cc78ef5456af593490eb","https://git.kernel.org/stable/c/8015ef9e8a0ee5cecfd0cb6805834d007ab26f86","https://git.kernel.org/stable/c/8423f0b6d513b259fdab9c9bf4aaa6188d054c2d","https://git.kernel.org/stable/c/fce793a056c604b41a298317cf704dae255f1b36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49579 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4: Fix data-races around sysctl_fib_multipath_hash_policy. While reading sysctl_fib_multipath_hash_policy, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/21fb844bc1dc1461f5038d655aa1a14f39e13049","https://git.kernel.org/stable/c/7998c12a08c97cc26660532c9f90a34bd7d8da5a","https://git.kernel.org/stable/c/918ee6592ab9a2ff5316d06cfd4aaef60ccabec6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49630 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix a data-race around sysctl_tcp_ecn_fallback. While reading sysctl_tcp_ecn_fallback, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/12b8d9ca7e678abc48195294494f1815b555d658","https://git.kernel.org/stable/c/1ec3d6c2626ee6e1b36b7bd006873a271406ba61","https://git.kernel.org/stable/c/8bcf7339f2cf70ea4461df6ea045d1aadfabfa11"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49632 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix a data-race around sysctl_icmp_errors_use_inbound_ifaddr. While reading sysctl_icmp_errors_use_inbound_ifaddr, it can be changed concurrently. Thus, we need to add READ_ONCE() to its reader. | ["https://git.kernel.org/stable/c/d2efabce81db7eed1c98fa1a3f203f0edd738ac3","https://git.kernel.org/stable/c/de9490c32bc10020efdd1509689a28f197d6dfb8","https://git.kernel.org/stable/c/f9617844e4d5d6331dbce3fb19a24e5bda201e58"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49633 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: icmp: Fix data-races around sysctl_icmp_echo_enable_probe. While reading sysctl_icmp_echo_enable_probe, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/05c615033174f1d19374f42285ccd8e9af13e427","https://git.kernel.org/stable/c/4a2f7083cc6cb72dade9a63699ca352fad26d1cd","https://git.kernel.org/stable/c/cce955efa0ab81f7fb72e22beed372054c86005c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49201 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ibmvnic: fix race between xmit and reset There is a race between reset and the transmit paths that can lead to ibmvnic_xmit() accessing an scrq after it has been freed in the reset path. It can result in a crash like: Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000016189f8 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic] LR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 Call Trace: [c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable) [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c9cfcc] sch_direct_xmit+0xec/0x330 [c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0 [c000000000c00ad4] __dev_queue_xmit+0x394/0x730 [c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding] [c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding] [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280 [c000000000c00ca4] __dev_queue_xmit+0x564/0x730 [c000000000cf97e0] neigh_hh_output+0xd0/0x180 [c000000000cfa69c] ip_finish_output2+0x31c/0x5c0 [c000000000cfd244] __ip_queue_xmit+0x194/0x4f0 [c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0 [c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0 [c000000000d2d984] tcp_retransmit_skb+0x34/0x130 [c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0 [c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330 [c000000000d317bc] tcp_write_timer+0x5c/0x200 [c000000000243270] call_timer_fn+0x50/0x1c0 [c000000000243704] __run_timers.part.0+0x324/0x460 [c000000000243894] run_timer_softirq+0x54/0xa0 [c000000000ea713c] __do_softirq+0x15c/0x3e0 [c000000000166258] __irq_exit_rcu+0x158/0x190 [c000000000166420] irq_exit+0x20/0x40 [c00000000002853c] timer_interrupt+0x14c/0x2b0 [c000000000009a00] decrementer_common_virt+0x210/0x220 --- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c The immediate cause of the crash is the access of tx_scrq in the following snippet during a reset, where the tx_scrq can be either NULL or an address that will soon be invalid: ibmvnic_xmit() { ... tx_scrq = adapter->tx_scrq[queue_num]; txq = netdev_get_tx_queue(netdev, queue_num); ind_bufp = &tx_scrq->ind_buf; if (test_bit(0, &adapter->resetting)) { ... } But beyond that, the call to ibmvnic_xmit() itself is not safe during a reset and the reset path attempts to avoid this by stopping the queue in ibmvnic_cleanup(). However just after the queue was stopped, an in-flight ibmvnic_complete_tx() could have restarted the queue even as the reset is progressing. Since the queue was restarted we could get a call to ibmvnic_xmit() which can then access the bad tx_scrq (or other fields). We cannot however simply have ibmvnic_complete_tx() check the ->resetting bit and skip starting the queue. This can race at the "back-end" of a good reset which just restarted the queue but has not cleared the ->resetting bit yet. If we skip restarting the queue due to ->resetting being true, the queue would remain stopped indefinitely potentially leading to transmit timeouts. IOW ->resetting is too broad for this purpose. Instead use a new flag that indicates whether or not the queues are active. Only the open/ reset paths control when the queues are active. ibmvnic_complete_tx() and others wake up the queue only if the queue is marked active. So we will have: A. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open() ->resetting = true ->tx_queues_active = false disable tx queues ... ->tx_queues_active = true start tx queues B. Tx interrupt in ibmvnic_complete_tx(): if (->tx_queues_active) netif_wake_subqueue(); To ensure that ->tx_queues_active and state of the queues are consistent, we need a lock which: - must also be taken in the interrupt path (ibmvnic_complete_tx()) - shared across the multiple ---truncated--- | ["https://git.kernel.org/stable/c/1bd58abf595b6cf1ba6dd47ec887c4c009155fc9","https://git.kernel.org/stable/c/4219196d1f662cb10a462eb9e076633a3fc31a15","https://git.kernel.org/stable/c/475f9cce98b63bc145b4efa66fa51175d4cb345f","https://git.kernel.org/stable/c/8507c6ade73cdbbbda5c3d31d67f52f2e1cf03fe"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49215 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xsk: Fix race at socket teardown Fix a race in the xsk socket teardown code that can lead to a NULL pointer dereference splat. The current xsk unbind code in xsk_unbind_dev() starts by setting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for any NAPI processing to terminate using synchronize_net(). After that, the release code starts to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: <TASK> ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae There are two problems with the current code. First, setting xs->dev to NULL before waiting for all users to stop using the socket is not correct. The entry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg() are all guarded by a test that xs->state is in the state XSK_BOUND and if not, it returns right away. But one process might have passed this test but still have not gotten to the point in which it uses xs->dev in the code. In this interim, a second process executing xsk_unbind_dev() might have set xs->dev to NULL which will lead to a crash for the first process. The solution here is just to get rid of this NULL assignment since it is not used anymore. Before commit 42fddcc7c64b ("xsk: use state member for socket synchronization"), xs->dev was the gatekeeper to admit processes into the data plane functions, but it was replaced with the state variable xs->state in the aforementioned commit. The second problem is that synchronize_net() does not wait for any process in xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that the state they rely on might be cleaned up prematurely. This can happen when the notifier gets called (at driver unload for example) as it uses xsk_unbind_dev(). Solve this by extending the RCU critical region from just the ndo_xsk_wakeup to the whole functions mentioned above, so that both the test of xs->state == XSK_BOUND and the last use of any member of xs is covered by the RCU critical section. This will guarantee that when synchronize_net() completes, there will be no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() and state can be cleaned up safely. Note that we need to drop the RCU lock for the skb xmit path as it uses functions that might sleep. Due to this, we have to retest the xs->state after we grab the mutex that protects the skb xmit code from, among a number of things, an xsk_unbind_dev() being executed from the notifier at the same time. | ["https://git.kernel.org/stable/c/18b1ab7aa76bde181bdb1ab19a87fa9523c32f21","https://git.kernel.org/stable/c/8a2dea162b92c322f3e42eae0c4a74b8d20aa7a9","https://git.kernel.org/stable/c/ad7219cd8751bd258b9d1e69ae0654ec00f71875","https://git.kernel.org/stable/c/d1579253ffce39986e7a6ab757ac93b2680a665f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49443 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: list: fix a data-race around ep->rdllist ep_poll() first calls ep_events_available() with no lock held and checks if ep->rdllist is empty by list_empty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing. Note INIT_LIST_HEAD_RCU() already has the annotation for both prev and next. Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless ep_events_available(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()") made some ep_events_available() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last ep_events_available() lockless. BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INIT_LIST_HEAD include/linux/list.h:38 [inline] list_splice_init include/linux/list.h:492 [inline] ep_start_scan fs/eventpoll.c:622 [inline] ep_send_events fs/eventpoll.c:1656 [inline] ep_poll fs/eventpoll.c:1806 [inline] do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: list_empty_careful include/linux/list.h:329 [inline] ep_events_available fs/eventpoll.c:381 [inline] ep_poll fs/eventpoll.c:1797 [inline] do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234 do_epoll_pwait fs/eventpoll.c:2268 [inline] __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline] __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275 __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0xffff88810480c7d0 -> 0xffff888103c15098 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 | ["https://git.kernel.org/stable/c/5d5d993f16be15d124be7b8ec71b28ef7b7dc3af","https://git.kernel.org/stable/c/cb3e48f7a35033deb9455abe3932e63cb500b9eb","https://git.kernel.org/stable/c/d679ae94fdd5d3ab00c35078f5af5f37e068b03d","https://git.kernel.org/stable/c/e039c0b5985999b150594126225e1ee51df7b4c9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49578 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ip: Fix data-races around sysctl_ip_prot_sock. sysctl_ip_prot_sock is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. | ["https://git.kernel.org/stable/c/95724fe897a4ecf2be51452ef96e818568071664","https://git.kernel.org/stable/c/9add240f76af6d141d2eebd3a1558a0e503a993d","https://git.kernel.org/stable/c/9b55c20f83369dd54541d9ddbe3a018a8377f451","https://git.kernel.org/stable/c/ef699813d99cc29e6e25c9f6da7766526cc8bd6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49585 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: Fix data-races around sysctl_tcp_fastopen_blackhole_timeout. While reading sysctl_tcp_fastopen_blackhole_timeout, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/021266ec640c7a4527e6cd4b7349a512b351de1d","https://git.kernel.org/stable/c/0dc2f19d8c2636cebda7976b5ea40c6d69f0d891","https://git.kernel.org/stable/c/8afa5604e295046c02b79ccf9e2bbbf8d969d60e","https://git.kernel.org/stable/c/a77a75a0e7f397550ab039f96115103e78dd5c69"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49629 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nexthop: Fix data-races around nexthop_compat_mode. While reading nexthop_compat_mode, it can be changed concurrently. Thus, we need to add READ_ONCE() to its readers. | ["https://git.kernel.org/stable/c/0d17723afea3ae8c9f245c9bbd2ba5945b77e812","https://git.kernel.org/stable/c/a51040d4b120f3520df64fb0b9c63b31d69bea9b","https://git.kernel.org/stable/c/ae3054f6fbccc90f14ecd6cf9b2c09a2401c64fd","https://git.kernel.org/stable/c/bdf00bf24bef9be1ca641a6390fd5487873e0d2e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49634 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data-races in proc_dou8vec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_dou8vec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_dou8vec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. | ["https://git.kernel.org/stable/c/5f776daef0b5354615ec4b4234cd9539ca05f273","https://git.kernel.org/stable/c/7dee5d7747a69aa2be41f04c6a7ecfe3ac8cdf18","https://git.kernel.org/stable/c/e58b02e445463065b4078bf621561da75197853f","https://git.kernel.org/stable/c/f177b382c33900d0e5a9766493c11a1074076f78"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49640 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec_minmax(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec_minmax() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec_minmax() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. | ["https://git.kernel.org/stable/c/2d3b559df3ed39258737789aae2ae7973d205bc1","https://git.kernel.org/stable/c/40e0477a7371d101c55b69d9c32a7a1ed82ab5ea","https://git.kernel.org/stable/c/b60eddf98b9716651069dfda296c91311a7a6293","https://git.kernel.org/stable/c/e3a2144b3b6bf9ecafd91087c8b8b48171ec19df"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49641 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sysctl: Fix data races in proc_douintvec(). A sysctl variable is accessed concurrently, and there is always a chance of data-race. So, all readers and writers need some basic protection to avoid load/store-tearing. This patch changes proc_douintvec() to use READ_ONCE() and WRITE_ONCE() internally to fix data-races on the sysctl side. For now, proc_douintvec() itself is tolerant to a data-race, but we still need to add annotations on the other subsystem's side. | ["https://git.kernel.org/stable/c/4762b532ec9539755aab61445d5da6e1926ccb99","https://git.kernel.org/stable/c/630c76850d554d7140232e71b5d1663e88cffb54","https://git.kernel.org/stable/c/d335db59f7fb3353f56e52371f1ee796ae9c8f09","https://git.kernel.org/stable/c/d5d54714e329f646bd7af4994fc427d88ee68936"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52926 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IORING_OP_READ did not correctly consume the provided buffer list when read i/o returned < 0 (except for -EAGAIN and -EIOCBQUEUED return). This can lead to a potential use-after-free when the completion via io_rw_done runs at separate context. | ["https://git.kernel.org/stable/c/6c27fc6a783c8a77c756dd5461b15e465020d075","https://git.kernel.org/stable/c/72060434a14caea20925e492310d6e680e3f9007","https://git.kernel.org/stable/c/a08d195b586a217d76b42062f88f375a3eedda4d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52444 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid dirent corruption As Al reported in link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); else f2fs_put_page(old_dir_page, 0); You want correct inumber in the ".." link. And cross-directory rename does move the source to new parent, even if you'd been asked to leave a whiteout in the old place. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ With below testcase, it may cause dirent corruption, due to it missed to call f2fs_set_link() to update ".." link to new directory. - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Bad inode number[0x4] for '..', parent parent ino is [0x3] [FSCK] other corrupted bugs [Fail] | ["https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46","https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862","https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28","https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024","https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310","https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728","https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7","https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77","https://git.kernel.org/stable/c/02160112e6d45c2610b049df6eb693d7a2e57b46","https://git.kernel.org/stable/c/2fb4867f4405aea8c0519d7d188207f232a57862","https://git.kernel.org/stable/c/53edb549565f55ccd0bdf43be3d66ce4c2d48b28","https://git.kernel.org/stable/c/5624a3c1b1ebc8991318e1cce2aa719542991024","https://git.kernel.org/stable/c/6f866885e147d33efc497f1095f35b2ee5ec7310","https://git.kernel.org/stable/c/d3c0b49aaa12a61d560528f5d605029ab57f0728","https://git.kernel.org/stable/c/f0145860c20be6bae6785c7a2249577674702ac7","https://git.kernel.org/stable/c/f100ba617d8be6c98a68f3744ef7617082975b77","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-40283 | High | fixed |
|
An issue was discovered in l2cap_sock_release in net/bluetooth/l2cap_sock.c in the Linux kernel before 6.4.10. There is a use-after-free because the children of an sk are mishandled. | ["http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231020-0007/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://github.com/torvalds/linux/commit/1728137b33c00d5a2b5110ed7aafb42e7c32e4a1","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20231020-0007/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52436 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: explicitly null-terminate the xattr list When setting an xattr, explicitly null-terminate the xattr list. This eliminates the fragile assumption that the unused xattr space is always zeroed. | ["https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a","https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135","https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36","https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11","https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52","https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a","https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564","https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea","https://git.kernel.org/stable/c/12cf91e23b126718a96b914f949f2cdfeadc7b2a","https://git.kernel.org/stable/c/16ae3132ff7746894894927c1892493693b89135","https://git.kernel.org/stable/c/2525d1ba225b5c167162fa344013c408e8b4de36","https://git.kernel.org/stable/c/32a6cfc67675ee96fe107aeed5af9776fec63f11","https://git.kernel.org/stable/c/3e47740091b05ac8d7836a33afd8646b6863ca52","https://git.kernel.org/stable/c/5de9e9dd1828db9b8b962f7ca42548bd596deb8a","https://git.kernel.org/stable/c/e26b6d39270f5eab0087453d9b544189a38c8564","https://git.kernel.org/stable/c/f6c30bfe5a49bc38cae985083a11016800708fea","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52604 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> ================================================================================ Kernel panic - not syncing: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 </TASK> Kernel Offset: disabled Rebooting in 86400 seconds.. The issue is caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a simple check solves this issue. Dave: As the function returns a void, good error handling would require a more intrusive code reorganization, so I modified Osama's patch at use WARN_ON_ONCE for lack of a cleaner option. The patch is tested via syzbot. | ["https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03","https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9","https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd","https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b","https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68","https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56","https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b","https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15","https://git.kernel.org/stable/c/42f433785f108893de0dd5260bafb85d7d51db03","https://git.kernel.org/stable/c/59342822276f753e49d27ef5eebffbba990572b9","https://git.kernel.org/stable/c/6a44065dd604972ec1fbcccbdc4a70d266a89cdd","https://git.kernel.org/stable/c/6fe8b702125aeee6ce83f20092a2341446704e7b","https://git.kernel.org/stable/c/9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68","https://git.kernel.org/stable/c/98f9537fe61b8382b3cc5dd97347531698517c56","https://git.kernel.org/stable/c/de34de6e57bbbc868e4fcf9e98c76b3587cabb0b","https://git.kernel.org/stable/c/e3e95c6850661c77e6dab079d9b5374a618ebb15","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-22995 | High | fixed |
|
In the Linux kernel before 5.17, an error path in dwc3_qcom_acpi_register_core in drivers/usb/dwc3/dwc3-qcom.c lacks certain platform_device_put and kfree calls. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2","https://security.netapp.com/advisory/ntap-20230331-0004/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/fa0ef93868a6062babe1144df2807a8b1d4924d2","https://security.netapp.com/advisory/ntap-20230331-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-34494 | Medium | fixed |
|
rpmsg_virtio_add_ctrl_dev in drivers/rpmsg/virtio_rpmsg_bus.c in the Linux kernel before 5.18.4 has a double free. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/1680939e9ecf7764fba8689cfb3429c2fe2bb23c","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/1680939e9ecf7764fba8689cfb3429c2fe2bb23c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52447 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Defer the free of inner map when necessary When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. | ["https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6","https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0","https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368","https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2","https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5","https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee","https://git.kernel.org/stable/c/37d98fb9c3144c0fddf7f6e99aece9927ac8dce6","https://git.kernel.org/stable/c/62fca83303d608ad4fec3f7428c8685680bb01b0","https://git.kernel.org/stable/c/876673364161da50eed6b472d746ef88242b2368","https://git.kernel.org/stable/c/90c445799fd1dc214d7c6279c144e33a35e29ef2","https://git.kernel.org/stable/c/bfd9b20c4862f41d4590fde11d70a5eeae53dcc5","https://git.kernel.org/stable/c/f91cd728b10c51f6d4a39957ccd56d1e802fc8ee","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48852 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/vc4: hdmi: Unregister codec device on unbind On bind we will register the HDMI codec device but we don't unregister it on unbind, leading to a device leakage. Unregister our device at unbind. | ["https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3","https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d","https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919","https://git.kernel.org/stable/c/1ed68d776246f167aee9cd79f63f089c40a5e2a3","https://git.kernel.org/stable/c/e40945ab7c7f966d0c37b7bd7b0596497dfe228d","https://git.kernel.org/stable/c/ee22082c3e2f230028afa0e22aa8773b1de3c919"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-26966 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 5.16.12. drivers/net/usb/sr9700.c allows attackers to obtain sensitive information from heap memory via crafted frame lengths from a device. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9da0b56fe27206b49f39805f7dcda8a89379062","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220419-0001/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.10","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9da0b56fe27206b49f39805f7dcda8a89379062","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220419-0001/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0286 | Medium | N/A | A flaw was found in the Linux kernel. A null pointer dereference in bond_ipsec_add_sa() may lead to local denial of service. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=105cd17a866017b45f3c45901b394c711c97bf40","https://syzkaller.appspot.com/bug?id=160f641886d88bf11cbf1236cc4db994bb210626","https://www.oracle.com/security-alerts/cpujul2022.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=105cd17a866017b45f3c45901b394c711c97bf40","https://syzkaller.appspot.com/bug?id=160f641886d88bf11cbf1236cc4db994bb210626","https://www.oracle.com/security-alerts/cpujul2022.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2308 | Medium | N/A | A flaw was found in vDPA with VDUSE backend. There are currently no checks in VDUSE kernel driver to ensure the size of the device config space is in line with the features advertised by the VDUSE userspace application. In case of a mismatch, Virtio drivers config read helpers do not initialize the memory indirectly passed to vduse_vdpa_get_config() returning uninitialized memory from the stack. This could cause undefined behavior or data leaks in Virtio drivers. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2103900","https://bugzilla.redhat.com/show_bug.cgi?id=2103900"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26898 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx(). | ["https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c","https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881","https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa","https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4","https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e","https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99","https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62","https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662","https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65","https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20aa1c969c","https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881","https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa","https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4","https://git.kernel.org/stable/c/a16fbb80064634b254520a46395e36b87ca4731e","https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99","https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62","https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662","https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-33203 | Medium | fixed |
|
The Linux kernel before 6.2.9 has a race condition and resultant use-after-free in drivers/net/ethernet/qualcomm/emac/emac.c if a physically proximate attacker unplugs an emac based device. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2192667","https://bugzilla.suse.com/show_bug.cgi?id=1210685","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75","https://bugzilla.redhat.com/show_bug.cgi?id=2192667","https://bugzilla.suse.com/show_bug.cgi?id=1210685","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-44032 | Medium | N/A | An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4000_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cmm_open() and cm4000_detach(). | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040701.GA302806%40ubuntu/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-44033 | Medium | N/A | An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/cm4040_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between cm4040_open() and reader_detach(). | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220915020834.GA110086%40ubuntu/","https://lore.kernel.org/lkml/20220919040457.GA302681%40ubuntu/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-44034 | Medium | N/A | An issue was discovered in the Linux kernel through 6.0.6. drivers/char/pcmcia/scr24x_cs.c has a race condition and resultant use-after-free if a physically proximate attacker removes a PCMCIA device while calling open(), aka a race condition between scr24x_open() and scr24x_remove(). | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/","https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9b12f050c76f090cc6d0aebe0ef76fed79ec3f15","https://lore.kernel.org/lkml/20220916050333.GA188358%40ubuntu/","https://lore.kernel.org/lkml/20220919101825.GA313940%40ubuntu/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22018 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: atm: Fix NULL pointer dereference When MPOA_cache_impos_rcvd() receives the msg, it can trigger Null Pointer Dereference Vulnerability if both entry and holding_time are NULL. Because there is only for the situation where entry is NULL and holding_time exists, it can be passed when both entry and holding_time are NULL. If these are NULL, the entry will be passd to eg_cache_put() as parameter and it is referenced by entry->use code in it. kasan log: [ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I [ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] [ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102 [ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470 [ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80 [ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006 [ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e [ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030 [ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88 [ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15 [ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068 [ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000 [ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0 [ 3.326430] Call Trace: [ 3.326725] <TASK> [ 3.326927] ? die_addr+0x3c/0xa0 [ 3.327330] ? exc_general_protection+0x161/0x2a0 [ 3.327662] ? asm_exc_general_protection+0x26/0x30 [ 3.328214] ? vprintk_emit+0x15e/0x420 [ 3.328543] ? eg_cache_remove_entry+0xa5/0x470 [ 3.328910] ? eg_cache_remove_entry+0x9a/0x470 [ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10 [ 3.329664] ? console_unlock+0x107/0x1d0 [ 3.329946] ? __pfx_console_unlock+0x10/0x10 [ 3.330283] ? do_syscall_64+0xa6/0x1a0 [ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f [ 3.331090] ? __pfx_prb_read_valid+0x10/0x10 [ 3.331395] ? down_trylock+0x52/0x80 [ 3.331703] ? vprintk_emit+0x15e/0x420 [ 3.331986] ? __pfx_vprintk_emit+0x10/0x10 [ 3.332279] ? down_trylock+0x52/0x80 [ 3.332527] ? _printk+0xbf/0x100 [ 3.332762] ? __pfx__printk+0x10/0x10 [ 3.333007] ? _raw_write_lock_irq+0x81/0xe0 [ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10 [ 3.333614] msg_from_mpoad+0x1185/0x2750 [ 3.333893] ? __build_skb_around+0x27b/0x3a0 [ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10 [ 3.334501] ? __alloc_skb+0x1c0/0x310 [ 3.334809] ? __pfx___alloc_skb+0x10/0x10 [ 3.335283] ? _raw_spin_lock+0xe0/0xe0 [ 3.335632] ? finish_wait+0x8d/0x1e0 [ 3.335975] vcc_sendmsg+0x684/0xba0 [ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10 [ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10 [ 3.337056] ? fdget+0x176/0x3e0 [ 3.337348] __sys_sendto+0x4a2/0x510 [ 3.337663] ? __pfx___sys_sendto+0x10/0x10 [ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400 [ 3.338364] ? sock_ioctl+0x1bb/0x5a0 [ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20 [ 3.339017] ? __pfx_sock_ioctl+0x10/0x10 [ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10 [ 3.339727] ? selinux_file_ioctl+0xa4/0x260 [ 3.340166] __x64_sys_sendto+0xe0/0x1c0 [ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140 [ 3.340898] do_syscall_64+0xa6/0x1a0 [ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 3.341533] RIP: 0033:0x44a380 [ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00 [ ---truncated--- | ["https://git.kernel.org/stable/c/09691f367df44fe93255274d80a439f9bb3263fc","https://git.kernel.org/stable/c/0ef6e49881b6b50ac454cb9d6501d009fdceb6fc","https://git.kernel.org/stable/c/14c7aca5ba2740973de27c1bb8df77b4dcb6f775","https://git.kernel.org/stable/c/1505f9b720656b17865e4166ab002960162bf679","https://git.kernel.org/stable/c/3c23bb2c894e9ef2727682f98c341b20f78c9013","https://git.kernel.org/stable/c/9da6b6340dbcf0f60ae3ec6a7d6438337c32518a","https://git.kernel.org/stable/c/ab92f51c7f53a08f1a686bfb80690ebb3672357d","https://git.kernel.org/stable/c/bf2986fcf82a449441f9ee4335df19be19e83970","https://git.kernel.org/stable/c/d7f1e4a53a51cc6ba833afcb40439f18dab61c1f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3104 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. lkdtm_ARRAY_BOUNDS in drivers/misc/lkdtm/bugs.c lacks check of the return value of kmalloc() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153062","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=4a9800c81d2f34afb66b4b42e0330ae8298019a2","https://bugzilla.redhat.com/show_bug.cgi?id=2153062","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=4a9800c81d2f34afb66b4b42e0330ae8298019a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3105 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. uapi_finalize in drivers/infiniband/core/uverbs_uapi.c lacks check of kmalloc_array(). | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153067","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=7694a7de22c53a312ea98960fcafc6ec62046531","https://bugzilla.redhat.com/show_bug.cgi?id=2153067","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=7694a7de22c53a312ea98960fcafc6ec62046531"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3106 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. ef100_update_stats in drivers/net/ethernet/sfc/ef100_nic.c lacks check of the return value of kmalloc(). | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153066","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=407ecd1bd726f240123f704620d46e285ff30dd9","https://bugzilla.redhat.com/show_bug.cgi?id=2153066","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=407ecd1bd726f240123f704620d46e285ff30dd9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3112 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. amvdec_set_canvases in drivers/staging/media/meson/vdec/vdec_helpers.c lacks check of the return value of kzalloc() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153068","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=c8c80c996182239ff9b05eda4db50184cf3b2e99","https://bugzilla.redhat.com/show_bug.cgi?id=2153068","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=c8c80c996182239ff9b05eda4db50184cf3b2e99"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3115 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. malidp_crtc_reset in drivers/gpu/drm/arm/malidp_crtc.c lacks check of the return value of kzalloc() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153058","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=73c3ed7495c67b8fbdc31cf58e6ca8757df31a33","https://bugzilla.redhat.com/show_bug.cgi?id=2153058","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=73c3ed7495c67b8fbdc31cf58e6ca8757df31a33"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52470 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref. | ["https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088","https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1","https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41","https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb","https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4","https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310","https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85","https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97","https://git.kernel.org/stable/c/0b813a6a0087451cb702b6eb841f10856f49d088","https://git.kernel.org/stable/c/14bbfaa5df273b26cde6707f6e655585700e6fe1","https://git.kernel.org/stable/c/21b1645660717d6126dd4866c850fcc5c4703a41","https://git.kernel.org/stable/c/57ca7984806d79b38af528de88fd803babf27feb","https://git.kernel.org/stable/c/5d12c5d75f7c78b83a738025947651ec5c95b4d4","https://git.kernel.org/stable/c/7a2464fac80d42f6f8819fed97a553e9c2f43310","https://git.kernel.org/stable/c/c4ff55408187f2595066967047363ca84e76db85","https://git.kernel.org/stable/c/fb2d8bc9b5e55848b8a7c3c028e2ee8d49f28f97","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52606 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/lib: Validate size for vector operations Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption. | ["https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf","https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c","https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414","https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd","https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59","https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e","https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678","https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b","https://git.kernel.org/stable/c/0580f4403ad33f379eef865c2a6fe94de37febdf","https://git.kernel.org/stable/c/28b8ba8eebf26f66d9f2df4ba550b6b3b136082c","https://git.kernel.org/stable/c/42084a428a139f1a429f597d44621e3a18f3e414","https://git.kernel.org/stable/c/848e1d7fd710900397e1d0e7584680c1c04e3afd","https://git.kernel.org/stable/c/8f9abaa6d7de0a70fc68acaedce290c1f96e2e59","https://git.kernel.org/stable/c/abd26515d4b767ba48241eea77b28ce0872aef3e","https://git.kernel.org/stable/c/beee482cc4c9a6b1dcffb2e190b4fd8782258678","https://git.kernel.org/stable/c/de4f5ed63b8a199704d8cdcbf810309d7eb4b36b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26663 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tipc: Check the bearer type before calling tipc_udp_nl_bearer_add() syzbot reported the following general protection fault [1]: general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087] ... RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291 ... Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The cause of this issue is that when tipc_nl_bearer_add() is called with the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called even if the bearer is not UDP. tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that the media_ptr field of the tipc_bearer has an udp_bearer type object, so the function goes crazy for non-UDP bearers. This patch fixes the issue by checking the bearer type before calling tipc_udp_nl_bearer_add() in tipc_nl_bearer_add(). | ["https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87","https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95","https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1","https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87","https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6","https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f","https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59","https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12","https://git.kernel.org/stable/c/0cd331dfd6023640c9669d0592bc0fd491205f87","https://git.kernel.org/stable/c/19d7314f2fb9515bdaac9829d4d8eb34edd1fe95","https://git.kernel.org/stable/c/24ec8f0da93b8a9fba11600be8a90f0d73fb46f1","https://git.kernel.org/stable/c/3871aa01e1a779d866fa9dfdd5a836f342f4eb87","https://git.kernel.org/stable/c/3d3a5b31b43515b5752ff282702ca546ec3e48b6","https://git.kernel.org/stable/c/6f70f0b412458c622a12d4292782c8e92e210c2f","https://git.kernel.org/stable/c/888e3524be87f3df9fa3c083484e4b62b3e3bb59","https://git.kernel.org/stable/c/c1701ea85ef0ec7be6a1b36c7da69f572ed2fd12","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26812 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Create persistent INTx handler A vulnerability exists where the eventfd for INTx signaling can be deconfigured, which unregisters the IRQ handler but still allows eventfds to be signaled with a NULL context through the SET_IRQS ioctl or through unmask irqfd if the device interrupt is pending. Ideally this could be solved with some additional locking; the igate mutex serializes the ioctl and config space accesses, and the interrupt handler is unregistered relative to the trigger, but the irqfd path runs asynchronous to those. The igate mutex cannot be acquired from the atomic context of the eventfd wake function. Disabling the irqfd relative to the eventfd registration is potentially incompatible with existing userspace. As a result, the solution implemented here moves configuration of the INTx interrupt handler to track the lifetime of the INTx context object and irq_type configuration, rather than registration of a particular trigger eventfd. Synchronization is added between the ioctl path and eventfd_signal() wrapper such that the eventfd trigger can be dynamically updated relative to in-flight interrupts or irqfd callbacks. | ["https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034","https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d","https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897","https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834","https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c","https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e","https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3","https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899","https://git.kernel.org/stable/c/0e09cf81959d9f12b75ad5c6dd53d237432ed034","https://git.kernel.org/stable/c/18c198c96a815c962adc2b9b77909eec0be7df4d","https://git.kernel.org/stable/c/27d40bf72dd9a6600b76ad05859176ea9a1b4897","https://git.kernel.org/stable/c/4c089cefe30924fbe20dd1ee92774ea1f5eca834","https://git.kernel.org/stable/c/4cb0d7532126d23145329826c38054b4e9a05e7c","https://git.kernel.org/stable/c/69276a555c740acfbff13fb5769ee9c92e1c828e","https://git.kernel.org/stable/c/7d29d4c72c1e196cce6969c98072a272d1a703b3","https://git.kernel.org/stable/c/b18fa894d615c8527e15d96b76c7448800e13899","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26813 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/platform: Create persistent IRQ handlers The vfio-platform SET_IRQS ioctl currently allows loopback triggering of an interrupt before a signaling eventfd has been configured by the user, which thereby allows a NULL pointer dereference. Rather than register the IRQ relative to a valid trigger, register all IRQs in a disabled state in the device open path. This allows mask operations on the IRQ to nest within the overall enable state governed by a valid eventfd signal. This decouples @masked, protected by the @locked spinlock from @trigger, protected via the @igate mutex. In doing so, it's guaranteed that changes to @trigger cannot race the IRQ handlers because the IRQ handler is synchronously disabled before modifying the trigger, and loopback triggering of the IRQ via ioctl is safe due to serialization with trigger changes via igate. For compatibility, request_irq() failures are maintained to be local to the SET_IRQS ioctl rather than a fatal error in the open device path. This allows, for example, a userspace driver with polling mode support to continue to work regardless of moving the request_irq() call site. This necessarily blocks all SET_IRQS access to the failed index. | ["https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e","https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5","https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29","https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086","https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375","https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362","https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a","https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f","https://git.kernel.org/stable/c/07afdfd8a68f9eea8db0ddc4626c874f29d2ac5e","https://git.kernel.org/stable/c/09452c8fcbd7817c06e8e3212d99b45917e603a5","https://git.kernel.org/stable/c/0f8d8f9c2173a541812dd750529f4a415117eb29","https://git.kernel.org/stable/c/62d4e43a569b67929eb3319780be5359694c8086","https://git.kernel.org/stable/c/675daf435e9f8e5a5eab140a9864dfad6668b375","https://git.kernel.org/stable/c/7932db06c82c5b2f42a4d1a849d97dba9ce4a362","https://git.kernel.org/stable/c/cc5838f19d39a5fef04c468199699d2a4578be3a","https://git.kernel.org/stable/c/d6bedd6acc0bcb1e7e010bc046032e47f08d379f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-27437 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Disable auto-enable of exclusive INTx IRQ Currently for devices requiring masking at the irqchip for INTx, ie. devices without DisINTx support, the IRQ is enabled in request_irq() and subsequently disabled as necessary to align with the masked status flag. This presents a window where the interrupt could fire between these events, resulting in the IRQ incrementing the disable depth twice. This would be unrecoverable for a user since the masked flag prevents nested enables through vfio. Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx is never auto-enabled, then unmask as required. | ["https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060","https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351","https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2","https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda","https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5","https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438","https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec","https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43","https://git.kernel.org/stable/c/139dfcc4d723ab13469881200c7d80f49d776060","https://git.kernel.org/stable/c/26389925d6c2126fb777821a0a983adca7ee6351","https://git.kernel.org/stable/c/2a4a666c45107206605b7b5bc20545f8aabc4fa2","https://git.kernel.org/stable/c/3b3491ad0f80d913e7d255941d4470f4a4d9bfda","https://git.kernel.org/stable/c/561d5e1998d58b54ce2bbbb3e843b669aa0b3db5","https://git.kernel.org/stable/c/b7a2f0955ffceffadfe098b40b50307431f45438","https://git.kernel.org/stable/c/bf0bc84a20e6109ab07d5dc072067bd01eb931ec","https://git.kernel.org/stable/c/fe9a7082684eb059b925c535682e68c34d487d43","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23002 | Medium | fixed |
|
In the Linux kernel before 5.16.3, drivers/bluetooth/hci_qca.c misinterprets the devm_gpiod_get_index_optional return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/6845667146a28c09b5dfc401c1ad112374087944","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/6845667146a28c09b5dfc401c1ad112374087944"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48864 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command request from the driver, presently there is no validation against the number of queue pairs to configure, or even if multiqueue had been negotiated or not is unverified. This may lead to kernel panic due to uninitialized resource for the queues were there any bogus request sent down by untrusted driver. Tie up the loose ends there. | ["https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230","https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e","https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb","https://git.kernel.org/stable/c/9f6effca75626c7a7c7620dabcb1a254ca530230","https://git.kernel.org/stable/c/e7e118416465f2ba8b55007e5b789823e101421e","https://git.kernel.org/stable/c/ed0f849fc3a63ed2ddf5e72cdb1de3bdbbb0f8eb"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-38600 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ALSA: Fix deadlocks with kctl removals at disconnection In snd_card_disconnect(), we set card->shutdown flag at the beginning, call callbacks and do sync for card->power_ref_sleep waiters at the end. The callback may delete a kctl element, and this can lead to a deadlock when the device was in the suspended state. Namely: * A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem. * The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks. An easy fix is to wake up sleepers before processing the driver disconnect callbacks but right after setting the card->shutdown flag. Then all sleepers will abort immediately, and the code flows again. So, basically this patch moves the wait_event() call at the right timing. While we're at it, just to be sure, call wait_event_all() instead of wait_event(), although we don't use exclusive events on this queue for now. | ["https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68","https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4","https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c","https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7","https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a","https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7","https://git.kernel.org/stable/c/2f103287ef7960854808930499d1181bd0145d68","https://git.kernel.org/stable/c/6b55e879e7bd023a03888fc6c8339edf82f576f4","https://git.kernel.org/stable/c/87988a534d8e12f2e6fc01fe63e6c1925dc5307c","https://git.kernel.org/stable/c/88ce3fe255d58a93624b467af036dc3519f309c7","https://git.kernel.org/stable/c/c2fb439f4f1425a961d20bec818fed2c2d9ef70a","https://git.kernel.org/stable/c/ff80185e7b7b547a0911fcfc8aefc61c3e8304d7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42329 | Medium | fixed |
|
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329). | ["http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt","http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23005 | Medium | fixed |
|
In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached. | ["https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee","https://bugzilla.suse.com/show_bug.cgi?id=1208844#c2","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2","https://github.com/torvalds/linux/commit/4a625ceee8a0ab0273534cb6b432ce6b331db5ee"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52585 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() Return invalid error code -EINVAL for invalid block id. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) | ["https://git.kernel.org/stable/c/0eb296233f86750102aa43b97879b8d8311f249a","https://git.kernel.org/stable/c/195a6289282e039024ad30ba66e6f94a4d0fbe49","https://git.kernel.org/stable/c/467139546f3fb93913de064461b1a43a212d7626","https://git.kernel.org/stable/c/7e6d6f27522bcd037856234b720ff607b9c4a09b","https://git.kernel.org/stable/c/92cb363d16ac1e41c9764cdb513d0e89a6ff4915","https://git.kernel.org/stable/c/b8d55a90fd55b767c25687747e2b24abd1ef8680","https://git.kernel.org/stable/c/c364e7a34c85c2154fb2e47561965d5b5a0b69b1","https://git.kernel.org/stable/c/0eb296233f86750102aa43b97879b8d8311f249a","https://git.kernel.org/stable/c/195a6289282e039024ad30ba66e6f94a4d0fbe49","https://git.kernel.org/stable/c/467139546f3fb93913de064461b1a43a212d7626","https://git.kernel.org/stable/c/7e6d6f27522bcd037856234b720ff607b9c4a09b","https://git.kernel.org/stable/c/92cb363d16ac1e41c9764cdb513d0e89a6ff4915","https://git.kernel.org/stable/c/b8d55a90fd55b767c25687747e2b24abd1ef8680","https://git.kernel.org/stable/c/c364e7a34c85c2154fb2e47561965d5b5a0b69b1","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26816 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. | ["https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03","https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723","https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088","https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40","https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a","https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b","https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa","https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c","https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af","https://git.kernel.org/stable/c/13edb509abc91c72152a11baaf0e7c060a312e03","https://git.kernel.org/stable/c/47635b112a64b7b208224962471e7e42f110e723","https://git.kernel.org/stable/c/52018aa146e3cf76569a9b1e6e49a2b7c8d4a088","https://git.kernel.org/stable/c/5cb59db49c9c0fccfd33b2209af4f7ae3c6ddf40","https://git.kernel.org/stable/c/a4e7ff1a74274e59a2de9bb57236542aa990d20a","https://git.kernel.org/stable/c/aaa8736370db1a78f0e8434344a484f9fd20be3b","https://git.kernel.org/stable/c/ae7079238f6faf1b94accfccf334e98b46a0c0aa","https://git.kernel.org/stable/c/af2a9f98d884205145fd155304a6955822ccca1c","https://git.kernel.org/stable/c/c7cff9780297d55d97ad068b68b703cfe53ef9af","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52488 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the initial register address is sent ($00), followed by all the FIFO data without having to resend the register address each time. In this mode, the IC doesn't increment the register address for each R/W byte. The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers. They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is that when the R/W size is more than 1 byte, these functions assume that the register address is incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_ versions in order to remove the manual cache control which was a workaround when using the _raw_ versions. FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses. | ["https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db","https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573","https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611","https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23","https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b","https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169","https://git.kernel.org/stable/c/084c24e788d9cf29c55564de368bf5284f2bb5db","https://git.kernel.org/stable/c/416b10d2817c94db86829fb92ad43ce7d002c573","https://git.kernel.org/stable/c/4e37416e4ee1b1bc17364a68973e0c63be89e611","https://git.kernel.org/stable/c/aa7cb4787698add9367b19f7afc667662c9bdb23","https://git.kernel.org/stable/c/dbf4ab821804df071c8b566d9813083125e6d97b","https://git.kernel.org/stable/c/e635f652696ef6f1230621cfd89c350cb5ec6169","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3107 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. netvsc_get_ethtool_stats in drivers/net/hyperv/netvsc_drv.c lacks check of the return value of kvmalloc_array() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153060","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=886e44c9298a6b428ae046e2fa092ca52e822e6a","https://bugzilla.redhat.com/show_bug.cgi?id=2153060","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=886e44c9298a6b428ae046e2fa092ca52e822e6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3108 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. kfd_parse_subtype_iolink in drivers/gpu/drm/amd/amdkfd/kfd_crat.c lacks check of the return value of kmemdup(). | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153052","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=abfaf0eee97925905e742aa3b0b72e04a918fa9e","https://bugzilla.redhat.com/show_bug.cgi?id=2153052","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=abfaf0eee97925905e742aa3b0b72e04a918fa9e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3111 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. free_charger_irq() in drivers/power/supply/wm8350_power.c lacks free of WM8350_IRQ_CHG_FAST_RDY, which is registered in wm8350_init_charger(). | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153059","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=6dee930f6f6776d1e5a7edf542c6863b47d9f078","https://bugzilla.redhat.com/show_bug.cgi?id=2153059","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=6dee930f6f6776d1e5a7edf542c6863b47d9f078"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49850 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix deadlock in nilfs_count_free_blocks() A semaphore deadlock can occur if nilfs_get_block() detects metadata corruption while locating data blocks and a superblock writeback occurs at the same time: task 1 task 2 ------ ------ * A file operation * nilfs_truncate() nilfs_get_block() down_read(rwsem A) <-- nilfs_bmap_lookup_contig() ... generic_shutdown_super() nilfs_put_super() * Prepare to write superblock * down_write(rwsem B) <-- nilfs_cleanup_super() * Detect b-tree corruption * nilfs_set_log_cursor() nilfs_bmap_convert_error() nilfs_count_free_blocks() __nilfs_error() down_read(rwsem A) <-- nilfs_set_error() down_write(rwsem B) <-- *** DEADLOCK *** Here, nilfs_get_block() readlocks rwsem A (= NILFS_MDT(dat_inode)->mi_sem) and then calls nilfs_bmap_lookup_contig(), but if it fails due to metadata corruption, __nilfs_error() is called from nilfs_bmap_convert_error() inside the lock section. Since __nilfs_error() calls nilfs_set_error() unless the filesystem is read-only and nilfs_set_error() attempts to writelock rwsem B (= nilfs->ns_sem) to write back superblock exclusively, hierarchical lock acquisition occurs in the order rwsem A -> rwsem B. Now, if another task starts updating the superblock, it may writelock rwsem B during the lock sequence above, and can deadlock trying to readlock rwsem A in nilfs_count_free_blocks(). However, there is actually no need to take rwsem A in nilfs_count_free_blocks() because it, within the lock section, only reads a single integer data on a shared struct with nilfs_sufile_get_ncleansegs(). This has been the case after commit aa474a220180 ("nilfs2: add local variable to cache the number of clean segments"), that is, even before this bug was introduced. So, this resolves the deadlock problem by just not taking the semaphore in nilfs_count_free_blocks(). | ["https://git.kernel.org/stable/c/1d4ff73062096c21b47954d2996b4df259777bda","https://git.kernel.org/stable/c/36ff974b0310771417c0be64b64aa221bd70d63d","https://git.kernel.org/stable/c/3c89ca6d3dfa6c09c515807a7a97a521f5d5147e","https://git.kernel.org/stable/c/8ac932a4921a96ca52f61935dbba64ea87bbd5dc","https://git.kernel.org/stable/c/8b4506cff6630bb474bb46a2a75c31e533a756ba","https://git.kernel.org/stable/c/abc082aac0d9b6b926038fc3adb7008306581be2","https://git.kernel.org/stable/c/cb029b54953420f7a2d65100f1c5107f14411bdc","https://git.kernel.org/stable/c/f0cc93080d4c09510b74ecba87fd778cca390bb1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22010 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup during bt pages loop Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bc Add a cond_resched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call cond_resched(). | ["https://git.kernel.org/stable/c/13a52f6c9ff99f7d88f81da535cb4e85eade662b","https://git.kernel.org/stable/c/25655580136de59ec89f09089dd28008ea440fc9","https://git.kernel.org/stable/c/4104b0023ff66b5df900d23dbf38310893deca79","https://git.kernel.org/stable/c/461eb4ddede266df8f181f578732bb01742c3fd6","https://git.kernel.org/stable/c/975355faba56c0751292ed15a90c3e2c7dc0aad6","https://git.kernel.org/stable/c/9ab20fec7a1ce3057ad86afd27bfd08420b7cd11","https://git.kernel.org/stable/c/efe544462fc0b499725364f90bd0f8bbf16f861a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-22014 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1] | ["https://git.kernel.org/stable/c/02612f1e4c34d94d6c8ee75bf7d254ed697e22d4","https://git.kernel.org/stable/c/0a566a79aca9851fae140536e0fc5b0853c90a90","https://git.kernel.org/stable/c/2eeb03ad9f42dfece63051be2400af487ddb96d2","https://git.kernel.org/stable/c/72a222b6af10c2a05a5fad0029246229ed8912c2","https://git.kernel.org/stable/c/daba84612236de3ab39083e62c9e326a654ebd20","https://git.kernel.org/stable/c/f2bbfd50e95bc117360f0f59e629aa03d821ebd6","https://git.kernel.org/stable/c/f4489260f5713c94e1966e5f20445bff262876f4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52593 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. | ["https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878","https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03","https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132","https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d","https://git.kernel.org/stable/c/3739121443f5114c6bcf6d841a5124deb006b878","https://git.kernel.org/stable/c/574dcd3126aa2eed75437137843f254b1190dd03","https://git.kernel.org/stable/c/9ab224744a47363f74ea29c6894c405e3bcf5132","https://git.kernel.org/stable/c/fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52632 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); | ["https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4","https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340","https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c","https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94","https://git.kernel.org/stable/c/1556c242e64cdffe58736aa650b0b395854fe4d4","https://git.kernel.org/stable/c/2a9de42e8d3c82c6990d226198602be44f43f340","https://git.kernel.org/stable/c/752312f6a79440086ac0f9b08d7776870037323c","https://git.kernel.org/stable/c/b602f098f716723fa5c6c96a486e0afba83b7b94"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53013 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ptdma: pt_core_execute_cmd() should use spinlock The interrupt handler (pt_core_irq_handler()) of the ptdma driver can be called from interrupt context. The code flow in this function can lead down to pt_core_execute_cmd() which will attempt to grab a mutex, which is not appropriate in interrupt context and ultimately leads to a kernel panic. The fix here changes this mutex to a spinlock, which has been verified to resolve the issue. | ["https://git.kernel.org/stable/c/13ba563c2c8055ba8a637c9f70bb833b43cb4207","https://git.kernel.org/stable/c/95e5fda3b5f9ed8239b145da3fa01e641cf5d53c","https://git.kernel.org/stable/c/ed0d8f731e0bf1bb12a7a37698ac613db20e2794"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4385 | Medium | N/A | A NULL pointer dereference flaw was found in dbFree in fs/jfs/jfs_dmap.c in the journaling file system (JFS) in the Linux Kernel. This issue may allow a local attacker to crash the system due to a missing sanity check. | ["https://access.redhat.com/security/cve/CVE-2023-4385","https://bugzilla.redhat.com/show_bug.cgi?id=2219272","https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f","https://access.redhat.com/security/cve/CVE-2023-4385","https://bugzilla.redhat.com/show_bug.cgi?id=2219272","https://github.com/torvalds/linux/commit/0d4837fdb796f99369cf7691d33de1b856bcaf1f"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6610 | High | N/A | An out-of-bounds read vulnerability was found in smb2_dump_detail in fs/smb/client/smb2ops.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information. | ["https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2023-6610","https://bugzilla.kernel.org/show_bug.cgi?id=218219","https://bugzilla.redhat.com/show_bug.cgi?id=2253614","https://access.redhat.com/errata/RHSA-2024:0723","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/errata/RHSA-2024:0725","https://access.redhat.com/errata/RHSA-2024:0881","https://access.redhat.com/errata/RHSA-2024:0897","https://access.redhat.com/errata/RHSA-2024:1248","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:2094","https://access.redhat.com/security/cve/CVE-2023-6610","https://bugzilla.kernel.org/show_bug.cgi?id=218219","https://bugzilla.redhat.com/show_bug.cgi?id=2253614"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-41858 | High | fixed |
|
A flaw was found in the Linux kernel. A NULL pointer dereference may occur while a slip driver is in progress to detach in sl_tx_timeout in drivers/net/slip/slip.c. This issue could allow an attacker to crash the system or leak internal kernel information. | ["https://github.com/torvalds/linux/commit/ec4eb8a86ade4d22633e1da2a7d85a846b7d1798","https://security.netapp.com/advisory/ntap-20230223-0006/","https://github.com/torvalds/linux/commit/ec4eb8a86ade4d22633e1da2a7d85a846b7d1798","https://security.netapp.com/advisory/ntap-20230223-0006/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26593 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. | ["https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a","https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c","https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2","https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9","https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f","https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21","https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7","https://git.kernel.org/stable/c/1f8d0691c50581ba6043f009ec9e8b9f78f09d5a","https://git.kernel.org/stable/c/491528935c9c48bf341d8b40eabc6c4fc5df6f2c","https://git.kernel.org/stable/c/609c7c1cc976e740d0fed4dbeec688b3ecb5dce2","https://git.kernel.org/stable/c/6be99c51829b24c914cef5bff6164877178e84d9","https://git.kernel.org/stable/c/7a14b8a477b88607d157c24aeb23e7389ec3319f","https://git.kernel.org/stable/c/c1c9d0f6f7f1dbf29db996bd8e166242843a5f21","https://git.kernel.org/stable/c/d074d5ff5ae77b18300e5079c6bda6342a4d44b7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1990 | Medium | fixed |
|
A use-after-free flaw was found in ndlc_remove in drivers/nfc/st-nci/ndlc.c in the Linux Kernel. This flaw could allow an attacker to crash the system due to a race problem. | ["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230312160837.2040857-1-zyytlz.wz%40163.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1734 | High | fixed |
|
A flaw in Linux Kernel found in nfcmrvl_nci_unregister_dev() in drivers/nfc/nfcmrvl/main.c can lead to use after free both read or write when non synchronized between cleanup routine and firmware download routine. | ["http://www.openwall.com/lists/oss-security/2022/06/05/4","http://www.openwall.com/lists/oss-security/2022/06/09/1","https://github.com/torvalds/linux/commit/d270453a0d9ec10bb8a802a142fb1b3601a83098","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0007/","https://www.debian.org/security/2022/dsa-5173","http://www.openwall.com/lists/oss-security/2022/06/05/4","http://www.openwall.com/lists/oss-security/2022/06/09/1","https://github.com/torvalds/linux/commit/d270453a0d9ec10bb8a802a142fb1b3601a83098","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220707-0007/","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35824 | High | fixed |
|
An issue was discovered in the Linux kernel before 6.3.2. A use-after-free was found in dm1105_remove in drivers/media/pci/dm1105/dm1105.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230803-0002/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5abda7a16698d4d1f47af1168d8fa2c640116b4a","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/all/49bb0b6a-e669-d4e7-d742-a19d2763e947%40xs4all.nl/","https://lore.kernel.org/lkml/20230318081506.795147-1-zyytlz.wz%40163.com/","https://security.netapp.com/advisory/ntap-20230803-0002/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-51043 | High | fixed |
|
In the Linux kernel before 6.4.5, drivers/gpu/drm/drm_atomic.c has a use-after-free during a race condition between a nonblocking atomic commit and a driver unload. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.5","https://github.com/torvalds/linux/commit/4e076c73e4f6e90816b30fcd4a0d7ab365087255","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.5","https://github.com/torvalds/linux/commit/4e076c73e4f6e90816b30fcd4a0d7ab365087255"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52480 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) --> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session. | ["https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be","https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f","https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b","https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f","https://git.kernel.org/stable/c/18ced78b0ebccc2d16f426143dc56ab3aad666be","https://git.kernel.org/stable/c/53ff5cf89142b978b1a5ca8dc4d4425e6a09745f","https://git.kernel.org/stable/c/a2ca5fd3dbcc665e1169044fa0c9e3eba779202b","https://git.kernel.org/stable/c/c77fd3e25a51ac92b0f1b347a96eff6a0b4f066f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52517 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer. | ["https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d","https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209","https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097","https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f","https://git.kernel.org/stable/c/1f11f4202caf5710204d334fe63392052783876d","https://git.kernel.org/stable/c/36b29974a7ad2ff604c24ad348f940506c7b1209","https://git.kernel.org/stable/c/4e149d524678431638ff378ef6025e4e89b71097","https://git.kernel.org/stable/c/bd1ec7f9983b5cd3c77e0f7cda3fa8aed041af2f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-34495 | Medium | fixed |
|
rpmsg_probe in drivers/rpmsg/virtio_rpmsg_bus.c in the Linux kernel before 5.18.4 has a double free. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/c2eecefec5df1306eafce28ccdf1ca159a552ecc","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.18.4","https://github.com/torvalds/linux/commit/c2eecefec5df1306eafce28ccdf1ca159a552ecc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-32296 | Low | fixed |
|
The Linux kernel before 5.17.9 allows TCP servers to identify clients by observing what source ports are used. This occurs because of use of Algorithm 4 ("Double-Hash Port Selection Algorithm") of RFC 6056. | ["https://arxiv.org/abs/2209.12993","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5","https://github.com/0xkol/rfc6056-device-tracker","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173","https://arxiv.org/abs/2209.12993","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4c2c8f03a5ab7cb04ec64724d7d176d00bcc91e5","https://github.com/0xkol/rfc6056-device-tracker","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1353 | High | fixed |
|
A vulnerability was found in the pfkey_register function in net/key/af_key.c in the Linux kernel. This flaw allows a local, unprivileged user to gain access to kernel memory, leading to a system crash or a leak of internal kernel information. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2066819","https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2066819","https://github.com/torvalds/linux/commit/9a564bccb78a76740ea9d75a259942df8143d02c","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-21505 | Medium | fixed |
|
In the linux kernel, if IMA appraisal is used with the "ima_appraise=log" boot param, lockdown can be defeated with kexec on any machine when Secure Boot is disabled or unavailable. IMA prevents setting "ima_appraise=log" from the boot param when Secure Boot is enabled, but this does not cover cases where lockdown is used without Secure Boot. CVSS 3.1 Base Score 6.7 (Confidentiality, Integrity, Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H). | ["https://git.kernel.org/linus/543ce63b664e2c2f9533d089a4664b559c3e6b5b","https://linux.oracle.com/cve/CVE-2022-21505.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-35788 | High | fixed |
|
An issue was discovered in fl_set_geneve_opt in net/sched/cls_flower.c in the Linux kernel before 6.3.7. It allows an out-of-bounds write in the flower classifier code via TCA_FLOWER_KEY_ENC_OPTS_GENEVE packets. This may result in denial of service or privilege escalation. | ["http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/06/17/1","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7","https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230714-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/06/07/1","http://packetstormsecurity.com/files/174577/Kernel-Live-Patch-Security-Notice-LSN-0097-1.html","http://www.openwall.com/lists/oss-security/2023/06/17/1","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.7","https://git.kernel.org/linus/4d56304e5827c8cc8cc18c75343d283af7c4825c","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20230714-0002/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://www.openwall.com/lists/oss-security/2023/06/07/1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26656 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix use-after-free bug The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl to the AMDGPU DRM driver on any ASICs with an invalid address and size. The bug was reported by Joonkyo Jung <joonkyoj@yonsei.ac.kr>. For example the following code: static void Syzkaller1(int fd) { struct drm_amdgpu_gem_userptr arg; int ret; arg.addr = 0xffffffffffff0000; arg.size = 0x80000000; /*2 Gb*/ arg.flags = 0x7; ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &arg); } Due to the address and size are not valid there is a failure in amdgpu_hmm_register->mmu_interval_notifier_insert->__mmu_interval_notifier_insert-> check_shl_overflow, but we even the amdgpu_hmm_register failure we still call amdgpu_hmm_unregister into amdgpu_gem_object_free which causes access to a bad address. The following stack is below when the issue is reproduced when Kazan is enabled: [ +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340 [ +0.000017] Code: ff ff 49 89 44 24 08 48 b8 00 01 00 00 00 00 ad de 4c 89 f7 49 89 47 40 48 83 c0 22 49 89 47 48 e8 ce d1 2d 01 e9 32 ff ff ff <0f> 0b e9 16 ff ff ff 4c 89 ef e8 fa 14 b3 ff e9 36 ff ff ff e8 80 [ +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246 [ +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b [ +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260 [ +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25 [ +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00 [ +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260 [ +0.000011] FS: 00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000 [ +0.000012] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0 [ +0.000010] Call Trace: [ +0.000006] <TASK> [ +0.000007] ? show_regs+0x6a/0x80 [ +0.000018] ? __warn+0xa5/0x1b0 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000018] ? report_bug+0x24a/0x290 [ +0.000022] ? handle_bug+0x46/0x90 [ +0.000015] ? exc_invalid_op+0x19/0x50 [ +0.000016] ? asm_exc_invalid_op+0x1b/0x20 [ +0.000017] ? kasan_save_stack+0x26/0x50 [ +0.000017] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x327/0x340 [ +0.000019] ? mmu_interval_notifier_remove+0x23b/0x340 [ +0.000020] ? __pfx_mmu_interval_notifier_remove+0x10/0x10 [ +0.000017] ? kasan_save_alloc_info+0x1e/0x30 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __kasan_kmalloc+0xb1/0xc0 [ +0.000018] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? __kasan_check_read+0x11/0x20 [ +0.000020] amdgpu_hmm_unregister+0x34/0x50 [amdgpu] [ +0.004695] amdgpu_gem_object_free+0x66/0xa0 [amdgpu] [ +0.004534] ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu] [ +0.004291] ? do_syscall_64+0x5f/0xe0 [ +0.000023] ? srso_return_thunk+0x5/0x5f [ +0.000017] drm_gem_object_free+0x3b/0x50 [drm] [ +0.000489] amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu] [ +0.004295] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004270] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? __this_cpu_preempt_check+0x13/0x20 [ +0.000015] ? srso_return_thunk+0x5/0x5f [ +0.000013] ? sysvec_apic_timer_interrupt+0x57/0xc0 [ +0.000020] ? srso_return_thunk+0x5/0x5f [ +0.000014] ? asm_sysvec_apic_timer_interrupt+0x1b/0x20 [ +0.000022] ? drm_ioctl_kernel+0x17b/0x1f0 [drm] [ +0.000496] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004272] ? drm_ioctl_kernel+0x190/0x1f0 [drm] [ +0.000492] drm_ioctl_kernel+0x140/0x1f0 [drm] [ +0.000497] ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu] [ +0.004297] ? __pfx_drm_ioctl_kernel+0x10/0x10 [d ---truncated--- | ["https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e","https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c","https://git.kernel.org/stable/c/2e13f88e01ae7e28a7e831bf5c2409c4748e0a60","https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c","https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605","https://git.kernel.org/stable/c/22207fd5c80177b860279653d017474b2812af5e","https://git.kernel.org/stable/c/22f665ecfd1225afa1309ace623157d12bb9bb0c","https://git.kernel.org/stable/c/af054a5fb24a144f99895afce9519d709891894c","https://git.kernel.org/stable/c/e87e08c94c9541b4e18c4c13f2f605935f512605"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3759 | Medium | N/A | A memory overflow vulnerability was found in the Linux kernel’s ipc functionality of the memcg subsystem, in the way a user calls the semget function multiple times, creating semaphores. This flaw allows a local user to starve the resources, causing a denial of service. The highest threat from this vulnerability is to system availability. | ["https://access.redhat.com/security/cve/CVE-2021-3759","https://bugzilla.redhat.com/show_bug.cgi?id=1999675","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/linux-mm/1626333284-1404-1-git-send-email-nglaive%40gmail.com/","https://access.redhat.com/security/cve/CVE-2021-3759","https://bugzilla.redhat.com/show_bug.cgi?id=1999675","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lore.kernel.org/linux-mm/1626333284-1404-1-git-send-email-nglaive%40gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52622 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid online resizing failures due to oversized flex bg When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: <TASK> __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. | ["https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0","https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954","https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c","https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07","https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644","https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8","https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90","https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2","https://git.kernel.org/stable/c/5d1935ac02ca5aee364a449a35e2977ea84509b0","https://git.kernel.org/stable/c/6d2cbf517dcabc093159cf138ad5712c9c7fa954","https://git.kernel.org/stable/c/8b1413dbfe49646eda2c00c0f1144ee9d3368e0c","https://git.kernel.org/stable/c/b183fe8702e78bba3dcef8e7193cab6898abee07","https://git.kernel.org/stable/c/cd1f93ca97a9136989f3bd2bf90696732a2ed644","https://git.kernel.org/stable/c/cfbbb3199e71b63fc26cee0ebff327c47128a1e8","https://git.kernel.org/stable/c/d76c8d7ffe163c6bf2f1ef680b0539c2b3902b90","https://git.kernel.org/stable/c/dc3e0f55bec4410f3d74352c4a7c79f518088ee2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50001 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure. | ["https://git.kernel.org/stable/c/26fad69b34fcba80d5c7d9e651f628e6ac927754","https://git.kernel.org/stable/c/2bcae12c795f32ddfbf8c80d1b5f1d3286341c32","https://git.kernel.org/stable/c/8bb8c12fb5e2b1f03d603d493c92941676f109b5","https://git.kernel.org/stable/c/ca36d6c1a49b6965c86dd528a73f38bc62d9c625","https://git.kernel.org/stable/c/ce828b347cf1b3c1b12b091d02463c35ce5097f5","https://git.kernel.org/stable/c/ecf310aaf256acbc8182189fe0aa1021c3ddef72","https://git.kernel.org/stable/c/fc357e78176945ca7bcacf92ab794b9ccd41b4f4"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52993 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/i8259: Mark legacy PIC interrupts with IRQ_LEVEL Baoquan reported that after triggering a crash the subsequent crash-kernel fails to boot about half of the time. It triggers a NULL pointer dereference in the periodic tick code. This happens because the legacy timer interrupt (IRQ0) is resent in software which happens in soft interrupt (tasklet) context. In this context get_irq_regs() returns NULL which leads to the NULL pointer dereference. The reason for the resend is a spurious APIC interrupt on the IRQ0 vector which is captured and leads to a resend when the legacy timer interrupt is enabled. This is wrong because the legacy PIC interrupts are level triggered and therefore should never be resent in software, but nothing ever sets the IRQ_LEVEL flag on those interrupts, so the core code does not know about their trigger type. Ensure that IRQ_LEVEL is set when the legacy PCI interrupts are set up. | ["https://git.kernel.org/stable/c/0b08201158f177aab469e356b4d6af24fdd118df","https://git.kernel.org/stable/c/137f1b47da5f58805da42c1b7811e28c1e353f39","https://git.kernel.org/stable/c/496975d1a2937f4baadf3d985991b13fc4fc4f27","https://git.kernel.org/stable/c/5fa55950729d0762a787451dc52862c3f850f859","https://git.kernel.org/stable/c/744fe9be9665227335539b7a77ece8d9ff62b6c0","https://git.kernel.org/stable/c/8770cd9d7c14aa99c255a0d08186f0be953e1638","https://git.kernel.org/stable/c/e284c273dbb4c1ed68d4204bff94d0b10e4a90f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53005 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: trace_events_hist: add check for return value of 'create_hist_field' Function 'create_hist_field' is called recursively at trace_events_hist.c:1954 and can return NULL-value that's why we have to check it to avoid null pointer dereference. Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/31b2414abeaa6de0490e85164badc6dcb1bb8ec9","https://git.kernel.org/stable/c/592ba7116fa620425725ff0972691f352ba3caf6","https://git.kernel.org/stable/c/886aa449235f478e262bbd5dcdee6ed6bc202949","https://git.kernel.org/stable/c/8b152e9150d07a885f95e1fd401fc81af202d9a4","https://git.kernel.org/stable/c/b4e7e81b4fdfcf457daee6b7a61769f62198d840","https://git.kernel.org/stable/c/d2d1ada58e7cc100b8d7d6b082d19321ba4a700a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-42752 | Medium | N/A | An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers. | ["http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/security/cve/CVE-2023-42752","https://bugzilla.redhat.com/show_bug.cgi?id=2239828","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/security/cve/CVE-2023-42752","https://bugzilla.redhat.com/show_bug.cgi?id=2239828","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=915d975b2ffa","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=c3b704d4a4a2"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49741 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: smscufx: fix error handling code in ufx_usb_probe The current error handling code in ufx_usb_probe have many unmatching issues, e.g., missing ufx_free_usb_list, destroy_modedb label should only include framebuffer_release, fb_dealloc_cmap only matches fb_alloc_cmap. My local syzkaller reports a memory leak bug: memory leak in ufx_usb_probe BUG: memory leak unreferenced object 0xffff88802f879580 (size 128): comm "kworker/0:7", pid 17416, jiffies 4295067474 (age 46.710s) hex dump (first 32 bytes): 80 21 7c 2e 80 88 ff ff 18 d0 d0 0c 80 88 ff ff .!|............. 00 d0 d0 0c 80 88 ff ff e0 ff ff ff 0f 00 00 00 ................ backtrace: [<ffffffff814c99a0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1045 [<ffffffff824d219c>] kmalloc include/linux/slab.h:553 [inline] [<ffffffff824d219c>] kzalloc include/linux/slab.h:689 [inline] [<ffffffff824d219c>] ufx_alloc_urb_list drivers/video/fbdev/smscufx.c:1873 [inline] [<ffffffff824d219c>] ufx_usb_probe+0x11c/0x15a0 drivers/video/fbdev/smscufx.c:1655 [<ffffffff82d17927>] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396 [<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline] [<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639 [<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 [<ffffffff827132da>] driver_probe_device+0x2a/0x120 drivers/base/dd.c:808 [<ffffffff82713c27>] __device_attach_driver+0xf7/0x150 drivers/base/dd.c:936 [<ffffffff82710137>] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427 [<ffffffff827136b5>] __device_attach+0x105/0x2d0 drivers/base/dd.c:1008 [<ffffffff82711d36>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487 [<ffffffff8270e242>] device_add+0x642/0xdc0 drivers/base/core.c:3517 [<ffffffff82d14d5f>] usb_set_configuration+0x8ef/0xb80 drivers/usb/core/message.c:2170 [<ffffffff82d2576c>] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238 [<ffffffff82d16ffc>] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293 [<ffffffff82712f0d>] call_driver_probe drivers/base/dd.c:560 [inline] [<ffffffff82712f0d>] really_probe+0x12d/0x390 drivers/base/dd.c:639 [<ffffffff8271322f>] __driver_probe_device+0xbf/0x140 drivers/base/dd.c:778 Fix this bug by rewriting the error handling code in ufx_usb_probe. | ["https://git.kernel.org/stable/c/1b4c08844628dfc8d72d3f51b657f2a5e63b7b4b","https://git.kernel.org/stable/c/3931014367ef31d26af65386a4ca496f50f0cfdf","https://git.kernel.org/stable/c/3b3d3127f5b4291ae4caaf50f7b66089ad600480","https://git.kernel.org/stable/c/64fa364ad3245508d393e16ed4886f92d7eb423c","https://git.kernel.org/stable/c/b76449ee75e21acfe9fa4c653d8598f191ed7d68"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49748 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf/x86/amd: fix potential integer overflow on shift of a int The left shift of int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then passed as a 64 bit function argument. In the case where i is 32 or more this can lead to an overflow. Avoid this by shifting using the BIT_ULL macro instead. | ["https://git.kernel.org/stable/c/08245672cdc6505550d1a5020603b0a8d4a6dcc7","https://git.kernel.org/stable/c/14cc13e433e1067557435b1adbf05608d7d47a93","https://git.kernel.org/stable/c/a4d01fb87ece45d4164fd725890211ccf9a307a9","https://git.kernel.org/stable/c/f84c9b72fb200633774704d8020f769c88a4b249","https://git.kernel.org/stable/c/fbf7b0e4cef3b5470b610f14fb9faa5ee7f63954"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52976 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: efi: fix potential NULL deref in efi_mem_reserve_persistent When iterating on a linked list, a result of memremap is dereferenced without checking it for NULL. This patch adds a check that falls back on allocating a new page in case memremap doesn't succeed. Found by Linux Verification Center (linuxtesting.org) with SVACE. [ardb: return -ENOMEM instead of breaking out of the loop] | ["https://git.kernel.org/stable/c/87d4ff18738fd71e7e3c10827c80257da6283697","https://git.kernel.org/stable/c/966d47e1f27c45507c5df82b2a2157e5a4fd3909","https://git.kernel.org/stable/c/a2e6a9ff89f13666a1c3ff7195612ab949ea9afc","https://git.kernel.org/stable/c/d8fc0b5fb3e816a4a8684bcd3ed02cbef0fce23c","https://git.kernel.org/stable/c/d92a25627bcdf264183670da73c9a60c0bac327e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53026 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Fix ib block iterator counter overflow When registering a new DMA MR after selecting the best aligned page size for it, we iterate over the given sglist to split each entry to smaller, aligned to the selected page size, DMA blocks. In given circumstances where the sg entry and page size fit certain sizes and the sg entry is not aligned to the selected page size, the total size of the aligned pages we need to cover the sg entry is >= 4GB. Under this circumstances, while iterating page aligned blocks, the counter responsible for counting how much we advanced from the start of the sg entry is overflowed because its type is u32 and we pass 4GB in size. This can lead to an infinite loop inside the iterator function because the overflow prevents the counter to be larger than the size of the sg entry. Fix the presented problem by changing the advancement condition to eliminate overflow. Backtrace: [ 192.374329] efa_reg_user_mr_dmabuf [ 192.376783] efa_register_mr [ 192.382579] pgsz_bitmap 0xfffff000 rounddown 0x80000000 [ 192.386423] pg_sz [0x80000000] umem_length[0xc0000000] [ 192.392657] start 0x0 length 0xc0000000 params.page_shift 31 params.page_num 3 [ 192.399559] hp_cnt[3], pages_in_hp[524288] [ 192.403690] umem->sgt_append.sgt.nents[1] [ 192.407905] number entries: [1], pg_bit: [31] [ 192.411397] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.415601] biter->__sg_advance [665837568] sg_dma_len[3221225472] [ 192.419823] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.423976] biter->__sg_advance [2813321216] sg_dma_len[3221225472] [ 192.428243] biter->__sg_nents [1] biter->__sg [0000000008b0c5d8] [ 192.432397] biter->__sg_advance [665837568] sg_dma_len[3221225472] | ["https://git.kernel.org/stable/c/0afec5e9cea732cb47014655685a2a47fb180c31","https://git.kernel.org/stable/c/362c9489720b31b6aa7491423ba65a4e98aa9838","https://git.kernel.org/stable/c/43811d07ea64366af8ec9e168c558ec51440c39e","https://git.kernel.org/stable/c/902063a9fea5f8252df392ade746bc9cfd07a5ae","https://git.kernel.org/stable/c/d66c1d4178c219b6e7d7a6f714e3e3656faccc36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26687 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xen/events: close evtchn after mapping cleanup shutdown_pirq and startup_pirq are not taking the irq_mapping_update_lock because they can't due to lock inversion. Both are called with the irq_desc->lock being taking. The lock order, however, is first irq_mapping_update_lock and then irq_desc->lock. This opens multiple races: - shutdown_pirq can be interrupted by a function that allocates an event channel: CPU0 CPU1 shutdown_pirq { xen_evtchn_close(e) __startup_pirq { EVTCHNOP_bind_pirq -> returns just freed evtchn e set_evtchn_to_irq(e, irq) } xen_irq_info_cleanup() { set_evtchn_to_irq(e, -1) } } Assume here event channel e refers here to the same event channel number. After this race the evtchn_to_irq mapping for e is invalid (-1). - __startup_pirq races with __unbind_from_irq in a similar way. Because __startup_pirq doesn't take irq_mapping_update_lock it can grab the evtchn that __unbind_from_irq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchn_to_irq. The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchn_to_irq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup. On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvme_setup_io_queues, pci_free_irq is called for every device which results in a call to shutdown_pirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdown_pirq and startup_pirq are running potentially in parallel. ------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/events_base.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x86_64 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvme_reset_work RIP: 0010:bind_evtchn_to_cpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_trace_log_lvl+0x1c1/0x2d9 ? show_trace_log_lvl+0x1c1/0x2d9 ? set_affinity_irq+0xdc/0x1c0 ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0x90/0x110 ? bind_evtchn_to_cpu+0xdf/0xf0 ? do_error_trap+0x65/0x80 ? bind_evtchn_to_cpu+0xdf/0xf0 ? exc_invalid_op+0x4e/0x70 ? bind_evtchn_to_cpu+0xdf/0xf0 ? asm_exc_invalid_op+0x12/0x20 ? bind_evtchn_to_cpu+0xdf/0x ---truncated--- | ["https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd","https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4","https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5","https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44","https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b","https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3","https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9","https://git.kernel.org/stable/c/0fc88aeb2e32b76db3fe6a624b8333dbe621b8fd","https://git.kernel.org/stable/c/20980195ec8d2e41653800c45c8c367fa1b1f2b4","https://git.kernel.org/stable/c/585a344af6bcac222608a158fc2830ff02712af5","https://git.kernel.org/stable/c/9470f5b2503cae994098dea9682aee15b313fa44","https://git.kernel.org/stable/c/9be71aa12afa91dfe457b3fb4a444c42b1ee036b","https://git.kernel.org/stable/c/ea592baf9e41779fe9a0424c03dd2f324feca3b3","https://git.kernel.org/stable/c/fa765c4b4aed2d64266b694520ecb025c862c5a9","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26688 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_super When configuring a hugetlb filesystem via the fsconfig() syscall, there is a possible NULL dereference in hugetlbfs_fill_super() caused by assigning NULL to ctx->hstate in hugetlbfs_parse_param() when the requested pagesize is non valid. E.g: Taking the following steps: fd = fsopen("hugetlbfs", FSOPEN_CLOEXEC); fsconfig(fd, FSCONFIG_SET_STRING, "pagesize", "1024", 0); fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0); Given that the requested "pagesize" is invalid, ctxt->hstate will be replaced with NULL, losing its previous value, and we will print an error: ... ... case Opt_pagesize: ps = memparse(param->string, &rest); ctx->hstate = h; if (!ctx->hstate) { pr_err("Unsupported page size %lu MB\n", ps / SZ_1M); return -EINVAL; } return 0; ... ... This is a problem because later on, we will dereference ctxt->hstate in hugetlbfs_fill_super() ... ... sb->s_blocksize = huge_page_size(ctx->hstate); ... ... Causing below Oops. Fix this by replacing cxt->hstate value only when then pagesize is known to be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G E 6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 <8b> 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS: 00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel: <TASK> kernel: ? __die_body+0x1a/0x60 kernel: ? page_fault_oops+0x16f/0x4a0 kernel: ? search_bpf_extables+0x65/0x70 kernel: ? fixup_exception+0x22/0x310 kernel: ? exc_page_fault+0x69/0x150 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: ? hugetlbfs_fill_super+0xb4/0x1a0 kernel: ? hugetlbfs_fill_super+0x28/0x1a0 kernel: ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel: vfs_get_super+0x40/0xa0 kernel: ? __pfx_bpf_lsm_capable+0x10/0x10 kernel: vfs_get_tree+0x25/0xd0 kernel: vfs_cmd_create+0x64/0xe0 kernel: __x64_sys_fsconfig+0x395/0x410 kernel: do_syscall_64+0x80/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? syscall_exit_to_user_mode+0x82/0x240 kernel: ? do_syscall_64+0x8d/0x160 kernel: ? exc_page_fault+0x69/0x150 kernel: entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff ---truncated--- | ["https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274","https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557","https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff","https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9","https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498","https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773","https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39","https://git.kernel.org/stable/c/13c5a9fb07105557a1fa9efdb4f23d7ef30b7274","https://git.kernel.org/stable/c/1dde8ef4b7a749ae1bc73617c91775631d167557","https://git.kernel.org/stable/c/22850c9950a4e43a67299755d11498f3292d02ff","https://git.kernel.org/stable/c/2e2c07104b4904aed1389a59b25799b95a85b5b9","https://git.kernel.org/stable/c/79d72c68c58784a3e1cd2378669d51bfd0cb7498","https://git.kernel.org/stable/c/80d852299987a8037be145a94f41874228f1a773","https://git.kernel.org/stable/c/ec78418801ef7b0c22cd6a30145ec480dd48db39","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26814 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/fsl-mc: Block calling interrupt handler without trigger The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. | ["https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417","https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d","https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9","https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012","https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede","https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d","https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267","https://git.kernel.org/stable/c/083e750c9f5f4c3bf61161330fb84d7c8e8bb417","https://git.kernel.org/stable/c/250219c6a556f8c69c5910fca05a59037e24147d","https://git.kernel.org/stable/c/6ec0d88166dac43f29e96801c0927d514f17add9","https://git.kernel.org/stable/c/7447d911af699a15f8d050dfcb7c680a86f87012","https://git.kernel.org/stable/c/a563fc18583ca4f42e2fdd0c70c7c618288e7ede","https://git.kernel.org/stable/c/de87511fb0404d23b6da5f4660383b6ed095e28d","https://git.kernel.org/stable/c/ee0bd4ad780dfbb60355b99f25063357ab488267","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49752 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: device property: fix of node refcount leak in fwnode_graph_get_next_endpoint() The 'parent' returned by fwnode_graph_get_port_parent() with refcount incremented when 'prev' is not NULL, it needs be put when finish using it. Because the parent is const, introduce a new variable to store the returned fwnode, then put it before returning from fwnode_graph_get_next_endpoint(). | ["https://git.kernel.org/stable/c/39af728649b05e88a2b40e714feeee6451c3f18e","https://git.kernel.org/stable/c/7701a4bd45c11f9a289d8f262fad05705a012339","https://git.kernel.org/stable/c/e75485fc589ec729cc182aa9b41dfb6c15ae6f6e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52936 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once. | ["https://git.kernel.org/stable/c/066ecbf1a53eb0b92b10c8df7808666be6ea5681","https://git.kernel.org/stable/c/cf1c917bf1c761a557b26410024e90057646c049","https://git.kernel.org/stable/c/d83d7ed260283560700d4034a80baad46620481b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49742 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation. | ["https://git.kernel.org/stable/c/92b4cf5b48955a4bdd15fe4e2067db8ebd87f04c","https://git.kernel.org/stable/c/ddeff03bb33810fcf2f0c18e03d099cf0aacda62"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52429 | Medium | fixed |
|
dm_table_create in drivers/md/dm-table.c in the Linux kernel through 6.7.4 can attempt to (in alloc_targets) allocate more than INT_MAX bytes, and crash, because of a missing check for struct dm_ioctl.target_count. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://www.spinics.net/lists/dm-devel/msg56625.html","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bd504bcfec41a503b32054da5472904b404341a4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://www.spinics.net/lists/dm-devel/msg56625.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-53090 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: <TASK> dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> | ["https://git.kernel.org/stable/c/610a79ffea02102899a1373fe226d949944a7ed6","https://git.kernel.org/stable/c/d7cbf81df996b1eae2dee8deb6df08e2eba78661"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26600 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] ... musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let's fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL. | ["https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4","https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4","https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1","https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b","https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d","https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5","https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462","https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3","https://git.kernel.org/stable/c/0430bfcd46657d9116a26cd377f112cbc40826a4","https://git.kernel.org/stable/c/14ef61594a5a286ae0d493b8acbf9eac46fd04c4","https://git.kernel.org/stable/c/396e17af6761b3cc9e6e4ca94b4de7f642bfece1","https://git.kernel.org/stable/c/486218c11e8d1c8f515a3bdd70d62203609d4b6b","https://git.kernel.org/stable/c/7104ba0f1958adb250319e68a15eff89ec4fd36d","https://git.kernel.org/stable/c/8398d8d735ee93a04fb9e9f490e8cacd737e3bf5","https://git.kernel.org/stable/c/8cc889b9dea0579726be9520fcc766077890b462","https://git.kernel.org/stable/c/be3b82e4871ba00e9b5d0ede92d396d579d7b3b3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52449 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mtd: Fix gluebi NULL pointer dereference caused by ftl notifier If both ftl.ko and gluebi.ko are loaded, the notifier of ftl triggers NULL pointer dereference when trying to access ‘gluebi->desc’ in gluebi_read(). ubi_gluebi_init ubi_register_volume_notifier ubi_enumerate_volumes ubi_notify_all gluebi_notify nb->notifier_call() gluebi_create mtd_device_register mtd_device_parse_register add_mtd_device blktrans_notify_add not->add() ftl_add_mtd tr->add_mtd() scan_header mtd_read mtd_read_oob mtd_read_oob_std gluebi_read mtd->read() gluebi->desc - NULL Detailed reproduction information available at the Link [1], In the normal case, obtain gluebi->desc in the gluebi_get_device(), and access gluebi->desc in the gluebi_read(). However, gluebi_get_device() is not executed in advance in the ftl_add_mtd() process, which leads to NULL pointer dereference. The solution for the gluebi module is to run jffs2 on the UBI volume without considering working with ftl or mtdblock [2]. Therefore, this problem can be avoided by preventing gluebi from creating the mtdblock device after creating mtd partition of the type MTD_UBIVOLUME. | ["https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8","https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745","https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5","https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6","https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022","https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc","https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65","https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c","https://git.kernel.org/stable/c/001a3f59d8c914ef8273461d4bf495df384cc5f8","https://git.kernel.org/stable/c/1bf4fe14e97cda621522eb2f28b0a4e87c5b0745","https://git.kernel.org/stable/c/5389407bba1eab1266c6d83e226fb0840cb98dd5","https://git.kernel.org/stable/c/a43bdc376deab5fff1ceb93dca55bcab8dbdc1d6","https://git.kernel.org/stable/c/aeba358bcc8ffddf9b4a9bd0e5ec9eb338d46022","https://git.kernel.org/stable/c/b36aaa64d58aaa2f2cbc8275e89bae76a2b6c3dc","https://git.kernel.org/stable/c/cfd7c9d260dc0a3baaea05a122a19ab91e193c65","https://git.kernel.org/stable/c/d8ac2537763b54d278b80b2b080e1652523c7d4c","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52619 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pstore/ram: Fix crash when setting number of cpus to an odd number When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. | ["https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee","https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c","https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a","https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4","https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10","https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542","https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c","https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb","https://git.kernel.org/stable/c/0593cfd321df9001142a9d2c58d4144917dff7ee","https://git.kernel.org/stable/c/2a37905d47bffec61e95d99f0c1cc5dc6377956c","https://git.kernel.org/stable/c/75b0f71b26b3ad833c5c0670109c0af6e021e86a","https://git.kernel.org/stable/c/8b69c30f4e8b69131d92096cb296dc1f217101e4","https://git.kernel.org/stable/c/a63e48cd835c34c38ef671d344cc029b1ea5bf10","https://git.kernel.org/stable/c/cd40e43f870cf21726b22487a95ed223790b3542","https://git.kernel.org/stable/c/d49270a04623ce3c0afddbf3e984cb245aa48e9c","https://git.kernel.org/stable/c/e9f6ac50890104fdf8194f2865680689239d30fb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26606 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won't trigger a wakeup either as the thread has pending work. | ["https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61","https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc","https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769","https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69","https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7","https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc","https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68","https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac","https://git.kernel.org/stable/c/42beab162dcee1e691ee4934292d51581c29df61","https://git.kernel.org/stable/c/82722b453dc2f967b172603e389ee7dc1b3137cc","https://git.kernel.org/stable/c/90e09c016d72b91e76de25f71c7b93d94cc3c769","https://git.kernel.org/stable/c/93b372c39c40cbf179e56621e6bc48240943af69","https://git.kernel.org/stable/c/97830f3c3088638ff90b20dfba2eb4d487bf14d7","https://git.kernel.org/stable/c/a423042052ec2bdbf1e552e621e6a768922363cc","https://git.kernel.org/stable/c/a7ae586f6f6024f490b8546c8c84670f96bb9b68","https://git.kernel.org/stable/c/dd64bb8329ce0ea27bc557e4160c2688835402ac","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49749 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i2c: designware: use casting of u64 in clock multiplication to avoid overflow In functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflow by depending on the values of the given parameters including the ic_clk. For example in our use case where ic_clk is larger than one million, multiplication of ic_clk * 4700 will result in 32 bit overflow. Add cast of u64 to the calculation to avoid multiplication overflow, and use the corresponding define for divide. | ["https://git.kernel.org/stable/c/2f29d780bd691d20e89e5b35d5e6568607115e94","https://git.kernel.org/stable/c/9f36aae9e80e79b7a6d62227eaa96935166be9fe","https://git.kernel.org/stable/c/c8c37bc514514999e62a17e95160ed9ebf75ca8d","https://git.kernel.org/stable/c/ed173f77fd28a3e4fffc13b3f28687b9eba61157"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52984 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83822: Fix null pointer access on DP83825/DP83826 devices The probe() function is only used for the DP83822 PHY, leaving the private data pointer uninitialized for the smaller DP83825/26 models. While all uses of the private data structure are hidden in 82822 specific callbacks, configuring the interrupt is shared across all models. This causes a NULL pointer dereference on the smaller PHYs as it accesses the private data unchecked. Verifying the pointer avoids that. | ["https://git.kernel.org/stable/c/2cd1e9c013ec56421c58921b1ddf1d2d53bd47fa","https://git.kernel.org/stable/c/362a2f5531dc0e5b0b5b3e3a541000dbffa75461","https://git.kernel.org/stable/c/422ae7d9c7221e8d4c8526d0f54106307d69d2dc","https://git.kernel.org/stable/c/78901b10522cdf6badf24acf65a892637596bccc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26640 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: add sanity checks to rx zerocopy TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) | ["https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60","https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894","https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e","https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e","https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760","https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f","https://git.kernel.org/stable/c/1b8adcc0e2c584fec778add7777fe28e20781e60","https://git.kernel.org/stable/c/577e4432f3ac810049cb7e6b71f4d96ec7c6e894","https://git.kernel.org/stable/c/718f446e60316bf606946f7f42367d691d21541e","https://git.kernel.org/stable/c/b383d4ea272fe5795877506dcce5aad1f6330e5e","https://git.kernel.org/stable/c/d15cc0f66884ef2bed28c7ccbb11c102aa3a0760","https://git.kernel.org/stable/c/f48bf9a83b1666d934247cb58a9887d7b3127b6f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26773 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb, group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group) // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap corrupted group | ["https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1","https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea","https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d","https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53","https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5","https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03","https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe","https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36","https://git.kernel.org/stable/c/0184747b552d6b5a14db3b7fcc3b792ce64dedd1","https://git.kernel.org/stable/c/21f8cfe79f776287459343e9cfa6055af61328ea","https://git.kernel.org/stable/c/260fc96283c0f594de18a1b045faf6d8fb42874d","https://git.kernel.org/stable/c/4530b3660d396a646aad91a787b6ab37cf604b53","https://git.kernel.org/stable/c/4c21fa60a6f4606f6214a38f50612b17b2f738f5","https://git.kernel.org/stable/c/927794a02169778c9c2e7b25c768ab3ea8c1dc03","https://git.kernel.org/stable/c/a2576ae9a35c078e488f2c573e9e6821d651fbbe","https://git.kernel.org/stable/c/f97e75fa4e12b0aa0224e83fcbda8853ac2adf36","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49932 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: <TASK> ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated--- | ["https://git.kernel.org/stable/c/04915240e2c3a018e4c7f23418478d27226c8957","https://git.kernel.org/stable/c/f7a1218a983ab98aba140dc20b25f60b39ee4033"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26651 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error. | ["https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61","https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581","https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7","https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009","https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a","https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384","https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028","https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f","https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774","https://git.kernel.org/stable/c/07161b2416f740a2cb87faa5566873f401440a61","https://git.kernel.org/stable/c/276873ae26c8d75b00747c1dadb9561d6ef20581","https://git.kernel.org/stable/c/424eba06ed405d557077339edb19ce0ebe39e7c7","https://git.kernel.org/stable/c/6b4a39acafaf0186ed8e97c16e0aa6fca0e52009","https://git.kernel.org/stable/c/8a8b6a24684bc278036c3f159f7b3a31ad89546a","https://git.kernel.org/stable/c/9c402819620a842cbfe39359a3ddfaac9adc8384","https://git.kernel.org/stable/c/e39a3a14eafcf17f03c037290b78c8f483529028","https://git.kernel.org/stable/c/efba65777f98457773c5b65e3135c6132d3b015f","https://git.kernel.org/stable/c/f546cc19f9b82975238d0ba413adc27714750774","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3344 | Medium | N/A | A flaw was found in the KVM's AMD nested virtualization (SVM). A malicious L1 guest could purposely fail to intercept the shutdown of a cooperative nested guest (L2), possibly leading to a page fault and kernel panic in the host (L0). | ["https://bugzilla.redhat.com/show_bug.cgi?id=2130278","https://lore.kernel.org/lkml/20221020093055.224317-5-mlevitsk%40redhat.com/T/","https://bugzilla.redhat.com/show_bug.cgi?id=2130278","https://lore.kernel.org/lkml/20221020093055.224317-5-mlevitsk%40redhat.com/T/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52616 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init When the mpi_ec_ctx structure is initialized, some fields are not cleared, causing a crash when referencing the field when the structure was released. Initially, this issue was ignored because memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag. For example, this error will be triggered when calculating the Za value for SM2 separately. | ["https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165","https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6","https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49","https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a","https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a","https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598","https://git.kernel.org/stable/c/0c3687822259a7628c85cd21a3445cbe3c367165","https://git.kernel.org/stable/c/2bb86817b33c9d704e127f92b838035a72c315b6","https://git.kernel.org/stable/c/7abdfd45a650c714d5ebab564bb1b988f14d9b49","https://git.kernel.org/stable/c/7ebf812b7019fd2d4d5a7ca45ef4bf3a6f4bda0a","https://git.kernel.org/stable/c/ba3c5574203034781ac4231acf117da917efcd2a","https://git.kernel.org/stable/c/bb44477d4506e52785693a39f03cdc6a2c5e8598","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26627 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart] | ["https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb","https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0","https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1","https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059","https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c","https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c","https://git.kernel.org/stable/c/07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb","https://git.kernel.org/stable/c/4373534a9850627a2695317944898eb1283a2db0","https://git.kernel.org/stable/c/65ead8468c21c2676d4d06f50b46beffdea69df1","https://git.kernel.org/stable/c/d37c1c81419fdef66ebd0747cf76fb8b7d979059","https://git.kernel.org/stable/c/db6338f45971b4285ea368432a84033690eaf53c","https://git.kernel.org/stable/c/f5944853f7a961fedc1227dc8f60393f8936d37c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2177 | Medium | fixed |
|
A null pointer dereference issue was found in the sctp network protocol in net/sctp/stream_sched.c in Linux Kernel. If stream_in allocation is failed, stream_out is freed which would further be accessed. A local user could use this flaw to crash the system or potentially cause a denial of service. | ["https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=181d8d2066c0","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=181d8d2066c0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52458 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. | ["https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503","https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016","https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62","https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5","https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8","https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8","https://git.kernel.org/stable/c/5010c27120962c85d2f421d2cf211791c9603503","https://git.kernel.org/stable/c/6f64f866aa1ae6975c95d805ed51d7e9433a0016","https://git.kernel.org/stable/c/8f6dfa1f1efe6dcca2d43e575491d8fcbe922f62","https://git.kernel.org/stable/c/bcdc288e7bc008daf38ef0401b53e4a8bb61bbe5","https://git.kernel.org/stable/c/cb16cc1abda18a9514106d2ac8c8d7abc0be5ed8","https://git.kernel.org/stable/c/ef31cc87794731ffcb578a195a2c47d744e25fb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26601 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd ("ext4: remove redundant mb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. | ["https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581","https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4","https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a","https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326","https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e","https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb","https://git.kernel.org/stable/c/6b0d48647935e4b8c7b75d1eccb9043fcd4ee581","https://git.kernel.org/stable/c/78327acd4cdc4a1601af718b781eece577b6b7d4","https://git.kernel.org/stable/c/94ebf71bddbcd4ab1ce43ae32c6cb66396d2d51a","https://git.kernel.org/stable/c/c1317822e2de80e78f137d3a2d99febab1b80326","https://git.kernel.org/stable/c/c9b528c35795b711331ed36dc3dbee90d5812d4e","https://git.kernel.org/stable/c/ea42d6cffb0dd27a417f410b9d0011e9859328cb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49920 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: netlink notifier might race to release objects commit release path is invoked via call_rcu and it runs lockless to release the objects after rcu grace period. The netlink notifier handler might win race to remove objects that the transaction context is still referencing from the commit release path. Call rcu_barrier() to ensure pending rcu callbacks run to completion if the list of transactions to be destroyed is not empty. | ["https://git.kernel.org/stable/c/1ffe7100411a8b9015115ce124cd6c9c9da6f8e3","https://git.kernel.org/stable/c/d4bc8271db21ea9f1c86a1ca4d64999f184d4aae","https://git.kernel.org/stable/c/e40b7c44d19e327ad8b49a491ef1fa8dcc4566e0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26830 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: i40e: Do not allow untrusted VF to remove administratively set MAC Currently when PF administratively sets VF's MAC address and the VF is put down (VF tries to delete all MACs) then the MAC is removed from MAC filters and primary VF MAC is zeroed. Do not allow untrusted VF to remove primary MAC when it was set administratively by PF. Reproducer: 1) Create VF 2) Set VF interface up 3) Administratively set the VF's MAC 4) Put VF interface down [root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs [root@host ~]# ip link set enp2s0f0v0 up [root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off [root@host ~]# ip link set enp2s0f0v0 down [root@host ~]# ip link show enp2s0f0 23: enp2s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off | ["https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893","https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc","https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404","https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d","https://git.kernel.org/stable/c/1c981792e4ccbc134b468797acdd7781959e6893","https://git.kernel.org/stable/c/73d9629e1c8c1982f13688c4d1019c3994647ccc","https://git.kernel.org/stable/c/be147926140ac48022c9605d7ab0a67387e4b404","https://git.kernel.org/stable/c/d250a81ba813a93563be68072c563aa1e346346d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0841 | High | fixed |
|
A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2024-0841","https://bugzilla.redhat.com/show_bug.cgi?id=2256490","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2024-0841","https://bugzilla.redhat.com/show_bug.cgi?id=2256490","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-56662 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl Fix an issue detected by syzbot with KASAN: BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/ core.c:416 [inline] BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0 drivers/acpi/nfit/core.c:459 The issue occurs in cmd_to_func when the call_pkg->nd_reserved2 array is accessed without verifying that call_pkg points to a buffer that is appropriately sized as a struct nd_cmd_pkg. This can lead to out-of-bounds access and undefined behavior if the buffer does not have sufficient space. To address this, a check was added in acpi_nfit_ctl() to ensure that buf is not NULL and that buf_len is less than sizeof(*call_pkg) before accessing it. This ensures safe access to the members of call_pkg, including the nd_reserved2 array. | ["https://git.kernel.org/stable/c/143f723e9eb4f0302ffb7adfdc7ef77eab3f68e0","https://git.kernel.org/stable/c/212846fafb753a48e869e2a342fc1e24048da771","https://git.kernel.org/stable/c/265e98f72bac6c41a4492d3e30a8e5fd22fe0779","https://git.kernel.org/stable/c/616aa5f3c86e0479bcbb81e41c08c43ff32af637","https://git.kernel.org/stable/c/bbdb3307f609ec4dc9558770f464ede01fe52aed","https://git.kernel.org/stable/c/e08dc2dc3c3f7938df0e4476fe3e6fdec5583c1d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2019 | Medium | fixed |
|
A flaw was found in the Linux kernel's netdevsim device driver, within the scheduling of events. This issue results from the improper management of a reference count. This may allow an attacker to create a denial of service condition on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2189137","https://github.com/torvalds/linux/commit/180a6a3ee60a","https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/","https://bugzilla.redhat.com/show_bug.cgi?id=2189137","https://github.com/torvalds/linux/commit/180a6a3ee60a","https://www.zerodayinitiative.com/advisories/ZDI-CAN-17811/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4387 | High | fixed |
|
A use-after-free flaw was found in vmxnet3_rq_alloc_rx_buf in drivers/net/vmxnet3/vmxnet3_drv.c in VMware's vmxnet3 ethernet NIC driver in the Linux Kernel. This issue could allow a local attacker to crash the system due to a double-free while cleaning up vmxnet3_rq_cleanup_all, which could also lead to a kernel information leak problem. | ["https://access.redhat.com/errata/RHSA-2022:8267","https://access.redhat.com/security/cve/CVE-2023-4387","https://bugzilla.redhat.com/show_bug.cgi?id=2219270","https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8","https://access.redhat.com/security/cve/CVE-2023-4387","https://bugzilla.redhat.com/show_bug.cgi?id=2219270","https://github.com/torvalds/linux/commit/9e7fef9521e73ca8afd7da9e58c14654b02dfad8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52519 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn't decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). | ["https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e","https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5","https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd","https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f","https://git.kernel.org/stable/c/60fb3f054c99608ddb1f2466c07108da6292951e","https://git.kernel.org/stable/c/8781fe259dd5a178fdd1069401bbd1437f9491c5","https://git.kernel.org/stable/c/8f02139ad9a7e6e5c05712f8c1501eebed8eacfd","https://git.kernel.org/stable/c/cdcc04e844a2d22d9d25cef1e8e504a174ea9f8f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52578 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq.c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703 worker_thread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 value changed: 0x00000000000d7190 -> 0x00000000000d7191 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0 | ["https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd","https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4","https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2","https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394","https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5","https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839","https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa","https://git.kernel.org/stable/c/04cc361f029c14dd067ad180525c7392334c9bfd","https://git.kernel.org/stable/c/44bdb313da57322c9b3c108eb66981c6ec6509f4","https://git.kernel.org/stable/c/89f9f20b1cbd36d99d5a248a4bf8d11d4fd049a2","https://git.kernel.org/stable/c/8bc97117b51d68d5cea8f5351cca2d8c4153f394","https://git.kernel.org/stable/c/ad8d39c7b437fcdab7208a6a56c093d222c008d5","https://git.kernel.org/stable/c/d2346e6beb699909ca455d9d20c4e577ce900839","https://git.kernel.org/stable/c/f2ef4cb4d418fa64fe73eb84d10cc5c0e52e00fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-42328 | Medium | fixed |
|
Guests can trigger deadlock in Linux netback driver T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] The patch for XSA-392 introduced another issue which might result in a deadlock when trying to free the SKB of a packet dropped due to the XSA-392 handling (CVE-2022-42328). Additionally when dropping packages for other reasons the same deadlock could occur in case of netpoll being active for the interface the xen-netback driver is connected to (CVE-2022-42329). | ["http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt","http://www.openwall.com/lists/oss-security/2022/12/08/2","http://www.openwall.com/lists/oss-security/2022/12/08/3","http://www.openwall.com/lists/oss-security/2022/12/09/2","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://xenbits.xenproject.org/xsa/advisory-424.txt"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1048 | High | fixed |
|
A use-after-free flaw was found in the Linux kernel’s sound subsystem in the way a user triggers concurrent calls of PCM hw_params. The hw_free ioctls or similar race condition happens inside ALSA PCM for other ioctls. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2066706","https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2066706","https://lore.kernel.org/lkml/20220322170720.3529-5-tiwai%40suse.de/T/#m1d3b791b815556012c6be92f1c4a7086b854f7f3","https://security.netapp.com/advisory/ntap-20220629-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52633 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: um: time-travel: fix time corruption In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled. | ["https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab","https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025","https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c","https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283","https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c","https://git.kernel.org/stable/c/0c7478a2da3f5fe106b4658338873d50c86ac7ab","https://git.kernel.org/stable/c/4f7dad73df4cdb2b7042103d3922745d040ad025","https://git.kernel.org/stable/c/abe4eaa8618bb36c2b33e9cdde0499296a23448c","https://git.kernel.org/stable/c/b427f55e9d4185f6f17cc1e3296eb8d0c4425283","https://git.kernel.org/stable/c/de3e9d8e8d1ae0a4d301109d1ec140796901306c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-32269 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 6.1.11. In net/netrom/af_netrom.c, there is a use-after-free because accept is also allowed for a successfully connected AF_NETROM socket. However, in order for an attacker to exploit this, the system must have netrom routing configured or the attacker must have the CAP_NET_ADMIN capability. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11","https://github.com/torvalds/linux/commit/611792920925fb088ddccbe2783c7f92fdfb6b64","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.11","https://github.com/torvalds/linux/commit/611792920925fb088ddccbe2783c7f92fdfb6b64"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-42155 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Wipe copies of protected- and secure-keys Although the clear-key of neither protected- nor secure-keys is accessible, this key material should only be visible to the calling process. So wipe all copies of protected- or secure-keys from stack, even in case of an error. | ["https://git.kernel.org/stable/c/c746f7ced4ad88ee48d0b6c92710e4674403185b","https://git.kernel.org/stable/c/f2ebdadd85af4f4d0cae1e5d009c70eccc78c207","https://git.kernel.org/stable/c/c746f7ced4ad88ee48d0b6c92710e4674403185b","https://git.kernel.org/stable/c/f2ebdadd85af4f4d0cae1e5d009c70eccc78c207"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-22997 | Medium | fixed |
|
In the Linux kernel before 6.1.2, kernel/module/decompress.c misinterprets the module_get_next_page return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.2","https://github.com/torvalds/linux/commit/45af1d7aae7d5520d2858f8517a1342646f015db","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.2","https://github.com/torvalds/linux/commit/45af1d7aae7d5520d2858f8517a1342646f015db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26801 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Avoid potential use-after-free in hci_error_reset While handling the HCI_EV_HARDWARE_ERROR event, if the underlying BT controller is not responding, the GPIO reset mechanism would free the hci_dev and lead to a use-after-free in hci_error_reset. Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth <HASH:3b4a6>] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth <HASH:3b4a 6>] hci_error_reset+0x4f/0xa4 [bluetooth <HASH:3b4a 6>] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30 This patch holds the reference count on the hci_dev while processing a HCI_EV_HARDWARE_ERROR event to avoid potential crash. | ["https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592","https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b","https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1","https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2","https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090","https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14","https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1","https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03","https://git.kernel.org/stable/c/2449007d3f73b2842c9734f45f0aadb522daf592","https://git.kernel.org/stable/c/2ab9a19d896f5a0dd386e1f001c5309bc35f433b","https://git.kernel.org/stable/c/45085686b9559bfbe3a4f41d3d695a520668f5e1","https://git.kernel.org/stable/c/6dd0a9dfa99f8990a08eb8fdd8e79bee31c7d8e2","https://git.kernel.org/stable/c/98fb98fd37e42fd4ce13ff657ea64503e24b6090","https://git.kernel.org/stable/c/da4569d450b193e39e87119fd316c0291b585d14","https://git.kernel.org/stable/c/dd594cdc24f2e48dab441732e6dfcafd6b0711d1","https://git.kernel.org/stable/c/e0b278650f07acf2e0932149183458468a731c03","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49899 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fscrypt: stop using keyrings subsystem for fscrypt_master_key The approach of fs/crypto/ internally managing the fscrypt_master_key structs as the payloads of "struct key" objects contained in a "struct key" keyring has outlived its usefulness. The original idea was to simplify the code by reusing code from the keyrings subsystem. However, several issues have arisen that can't easily be resolved: - When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free. - When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore. - More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped. - Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done. The fix for all these issues is to change the implementation to what I should have done originally: don't use the keyrings subsystem to keep track of the filesystem's fscrypt_master_key structs. Instead, just store them in a regular kernel data structure, and rework the reference counting, locking, and lifetime accordingly. Retain support for RCU-mode key lookups by using a hash table. Replace fscrypt_sb_free() with fscrypt_sb_delete(), which releases the keys synchronously and runs a bit earlier during unmount, so that block devices are still available. A side effect of this patch is that neither the master keys themselves nor the filesystem keyrings will be listed in /proc/keys anymore. ("Master key users" and the master key users keyrings will still be listed.) However, this was mostly an implementation detail, and it was intended just for debugging purposes. I don't know of anyone using it. This patch does *not* change how "master key users" (->mk_users) works; that still uses the keyrings subsystem. That is still needed for key quotas, and changing that isn't necessary to solve the issues listed above. If we decide to change that too, it would be a separate patch. I've marked this as fixing the original commit that added the fscrypt keyring, but as noted above the most important issue that this patch fixes wasn't introduced until the addition of inline encryption support. | ["https://git.kernel.org/stable/c/391cceee6d435e616f68631e68f5b32d480b1e67","https://git.kernel.org/stable/c/68d15d6558a386f46d815a6ac39edecad713a1bf","https://git.kernel.org/stable/c/d7e7b9af104c7b389a0c21eb26532511bce4b510","https://git.kernel.org/stable/c/e6f4fd85ef1ee6ab356bfbd64df28c1cb73aee7e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26870 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102 A call to listxattr() with a buffer size = 0 returns the actual size of the buffer needed for a subsequent call. When size > 0, nfs4_listxattr() does not return an error because either generic_listxattr() or nfs4_listxattr_nfs4_label() consumes exactly all the bytes then size is 0 when calling nfs4_listxattr_nfs4_user() which then triggers the following kernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000) Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl', thus calling lisxattr() with size = 16 will trigger the bug. Add check on nfs4_listxattr() to return ERANGE error when it is called with size > 0 and the return value is greater than size. | ["https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb","https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf","https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65","https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b","https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768","https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf","https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a","https://git.kernel.org/stable/c/06e828b3f1b206de08ef520fc46a40b22e1869cb","https://git.kernel.org/stable/c/23bfecb4d852751d5e403557dd500bb563313baf","https://git.kernel.org/stable/c/251a658bbfceafb4d58c76b77682c8bf7bcfad65","https://git.kernel.org/stable/c/4403438eaca6e91f02d272211c4d6b045092396b","https://git.kernel.org/stable/c/79cdcc765969d23f4e3d6ea115660c3333498768","https://git.kernel.org/stable/c/80365c9f96015bbf048fdd6c8705d3f8770132bf","https://git.kernel.org/stable/c/9d52865ff28245fc2134da9f99baff603a24407a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52454 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq(). | ["https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88","https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42","https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d","https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68","https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d","https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be","https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510","https://git.kernel.org/stable/c/24e05760186dc070d3db190ca61efdbce23afc88","https://git.kernel.org/stable/c/2871aa407007f6f531fae181ad252486e022df42","https://git.kernel.org/stable/c/4cb3cf7177ae3666be7fb27d4ad4d72a295fb02d","https://git.kernel.org/stable/c/70154e8d015c9b4fb56c1a2ef1fc8b83d45c7f68","https://git.kernel.org/stable/c/ee5e7632e981673f42a50ade25e71e612e543d9d","https://git.kernel.org/stable/c/efa56305908ba20de2104f1b8508c6a7401833be","https://git.kernel.org/stable/c/f775f2621c2ac5cc3a0b3a64665dad4fb146e510","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26684 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: xgmac: fix handling of DPP safety error for DMA channels Commit 56e58d6c8a56 ("net: stmmac: Implement Safety Features in XGMAC core") checks and reports safety errors, but leaves the Data Path Parity Errors for each channel in DMA unhandled at all, lead to a storm of interrupt. Fix it by checking and clearing the DMA_DPP_Interrupt_Status register. | ["https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37","https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2","https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3","https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89","https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf","https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591","https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00","https://git.kernel.org/stable/c/2fc45a4631ac7837a5c497cb4f7e2115d950fc37","https://git.kernel.org/stable/c/3b48c9e258c8691c2f093ee07b1ea3764caaa1b2","https://git.kernel.org/stable/c/46eba193d04f8bd717e525eb4110f3c46c12aec3","https://git.kernel.org/stable/c/6609e98ed82966a1b3168c142aca30f8284a7b89","https://git.kernel.org/stable/c/7e0ff50131e9d1aa507be8e670d38e9300a5f5bf","https://git.kernel.org/stable/c/e42ff0844fe418c7d03a14f9f90e1b91ba119591","https://git.kernel.org/stable/c/e9837c83befb5b852fa76425dde98a87b737df00","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-45862 | Medium | fixed |
|
An issue was discovered in drivers/usb/storage/ene_ub6250.c for the ENE UB6250 reader driver in the Linux kernel before 6.2.5. An object could potentially extend beyond the end of an allocation. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef","https://security.netapp.com/advisory/ntap-20231116-0004/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.5","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ce33e64c1788912976b61314b56935abd4bc97ef","https://security.netapp.com/advisory/ntap-20231116-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52932 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: add cond_resched() in get_swap_pages() The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently. The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup. | ["https://git.kernel.org/stable/c/29f0349c5c76b627fe06b87d4b13fa03a6ce8e64","https://git.kernel.org/stable/c/30187be29052bba9203b0ae2bdd815e0bc2faaab","https://git.kernel.org/stable/c/387217b97e99699c34e6d95ce2b91b327fcd853e","https://git.kernel.org/stable/c/49178d4d61e78aed8c837dfeea8a450700f196e2","https://git.kernel.org/stable/c/5dbe1ebd56470d03b78fc31491a9e4d433106ef2","https://git.kernel.org/stable/c/7717fc1a12f88701573f9ed897cc4f6699c661e3","https://git.kernel.org/stable/c/d49c85a1913385eed46dd16a25ad0928253767f0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23001 | Medium | fixed |
|
In the Linux kernel before 5.16.3, drivers/scsi/ufs/ufs-mediatek.c misinterprets the regulator_get return value (expects it to be NULL in the error case, whereas it is actually an error pointer). | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/3ba880a12df5aa4488c18281701b5b1bc3d4531a","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.3","https://github.com/torvalds/linux/commit/3ba880a12df5aa4488c18281701b5b1bc3d4531a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53016 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes. | ["https://git.kernel.org/stable/c/17511bd84871f4a6106cb335616e086880313f3f","https://git.kernel.org/stable/c/1d80d57ffcb55488f0ec0b77928d4f82d16b6a90","https://git.kernel.org/stable/c/98aec50ff7f60cc6f2d6a4396b475c547e58b04d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53022 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() This lockdep splat says it better than I could: ================================ WARNING: inconsistent lock state 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 irq event stamp: 7825 hardirqs last enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130 hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8 softirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8 softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); <Interrupt> lock(_xmit_ETHER#2); *** DEADLOCK *** 3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34 Workqueue: events enetc_tx_onestep_tstamp Call trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11c but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in process context, therefore with softirqs enabled (i.o.w., it can be interrupted by a softirq). If we hold the netif_tx_lock() when there is an interrupt, and the NET_TX softirq then gets scheduled, this will take the netif_tx_lock() a second time and deadlock the kernel. To solve this, use netif_tx_lock_bh(), which blocks softirqs from running. | ["https://git.kernel.org/stable/c/3c463721a73bdb57a913e0d3124677a3758886fc","https://git.kernel.org/stable/c/8232e5a84d25a84a5cbda0f241a00793fb6eb608","https://git.kernel.org/stable/c/e893dced1a18e77b1262f5c10169413f0ece0da7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49155 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Suppress a kernel complaint in qla_create_qpair() [ 12.323788] BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x86_64 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dump_stack_lvl+0x34/0x44 [ 12.362514] check_preemption_disabled+0xd9/0xe0 [ 12.367164] qla2xxx_create_qpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00_probe_one+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _raw_spin_lock_irqsave+0x19/0x40 [ 12.384284] local_pci_probe+0x42/0x80 [ 12.390162] ? pci_match_device+0xd7/0x110 [ 12.396366] pci_device_probe+0xfd/0x1b0 [ 12.402372] really_probe+0x1e7/0x3e0 [ 12.408114] __driver_probe_device+0xfe/0x180 [ 12.414544] driver_probe_device+0x1e/0x90 [ 12.420685] __driver_attach+0xc0/0x1c0 [ 12.426536] ? __device_attach_driver+0xe0/0xe0 [ 12.433061] ? __device_attach_driver+0xe0/0xe0 [ 12.439538] bus_for_each_dev+0x78/0xc0 [ 12.445294] bus_add_driver+0x12b/0x1e0 [ 12.451021] driver_register+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00_module_init+0x1be/0x229 [qla2xxx] [ 12.468776] do_one_initcall+0x44/0x200 [ 12.474401] ? load_module+0xad3/0xba0 [ 12.479908] ? kmem_cache_alloc_trace+0x45/0x410 [ 12.486268] do_init_module+0x5c/0x280 [ 12.491730] __do_sys_init_module+0x12e/0x1b0 [ 12.497785] do_syscall_64+0x3b/0x90 [ 12.503029] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e | ["https://git.kernel.org/stable/c/1ab81d82fb1db7ec4be4b0d04563513e6d4bcdd5","https://git.kernel.org/stable/c/43195a0c620761fbb88db04e2475313855b948a4","https://git.kernel.org/stable/c/8077a7162bc3cf658dd9ff112bc77716c08458c5","https://git.kernel.org/stable/c/9c33d49ab9f3d8bd7512b3070cd2f07c4a8849d5","https://git.kernel.org/stable/c/a60447e7d451df42c7bde43af53b34f10f34f469","https://git.kernel.org/stable/c/a669a22aef0ceff706b885370af74b5a60a8ac85","https://git.kernel.org/stable/c/f68776f28d9134fa65056e7e63bfc734049730b7","https://git.kernel.org/stable/c/f97316dd393bc8df1cc2af6295a97b876eecf252"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26915 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Reset IH OVERFLOW_CLEAR bit Allows us to detect subsequent IH ring buffer overflows as well. | ["https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d","https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd","https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70","https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1","https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2","https://git.kernel.org/stable/c/2827633c9dab6304ec4cdbf369363219832e605d","https://git.kernel.org/stable/c/7330256268664ea0a7dd5b07a3fed363093477dd","https://git.kernel.org/stable/c/8983397951b4b0bd51bb4b4ba9749424e1ccbb70","https://git.kernel.org/stable/c/9a9d00c23d170d4ef5a1b28e6b69f5c85dd12bc1","https://git.kernel.org/stable/c/a28f4d1e0bed85943d309ac243fd1c200f8af9a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52634 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix disable_otg_wa logic [Why] When switching to another HDMI mode, we are unnecesarilly disabling/enabling FIFO causing both HPO and DIG registers to be set at the same time when only HPO is supposed to be set. This can lead to a system hang the next time we change refresh rates as there are cases when we don't disable OTG/FIFO but FIFO is enabled when it isn't supposed to be. [How] Removing the enable/disable FIFO entirely. | ["https://git.kernel.org/stable/c/2ce156482a6fef349d2eba98e5070c412d3af662","https://git.kernel.org/stable/c/ce29728ef6485a367934cc100249c66dd3cde5b6","https://git.kernel.org/stable/c/2ce156482a6fef349d2eba98e5070c412d3af662","https://git.kernel.org/stable/c/ce29728ef6485a367934cc100249c66dd3cde5b6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26757 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. | ["https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3","https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b","https://git.kernel.org/stable/c/2ea169c5a0b1134d573d07fc27a16f327ad0e7d3","https://git.kernel.org/stable/c/55a48ad2db64737f7ffc0407634218cc6e4c513b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-23849 | Medium | N/A | In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access. | ["https://bugzilla.suse.com/show_bug.cgi?id=1219127","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13e788deb7348cc88df34bed736c3b3b9927ea52","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/1705715319-19199-1-git-send-email-sharath.srinivasan%40oracle.com/","https://lore.kernel.org/netdev/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw%40mail.gmail.com","https://bugzilla.suse.com/show_bug.cgi?id=1219127","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13e788deb7348cc88df34bed736c3b3b9927ea52","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/1705715319-19199-1-git-send-email-sharath.srinivasan%40oracle.com/","https://lore.kernel.org/netdev/CALGdzuoVdq-wtQ4Az9iottBqC5cv9ZhcE5q8N7LfYFvkRsOVcw%40mail.gmail.com"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26896 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: fix memory leak when starting AP Kmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [<f83ea192>] kmalloc_reserve.constprop.0+0x30/0x74 [<a2c61343>] __alloc_skb+0xa0/0x170 [<fb8a5e38>] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [<a4a661cd>] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [<f965b9b6>] netlink_sendmsg+0x1e8/0x428 [<aadb8231>] ____sys_sendmsg+0x1e0/0x274 [<d2b5212d>] ___sys_sendmsg+0x80/0xb4 However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy. | ["https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3","https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b","https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3","https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc","https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487","https://git.kernel.org/stable/c/12f00a367b2b62756e0396f14b54c2c15524e1c3","https://git.kernel.org/stable/c/3a71ec74e5e3478d202a1874f085ca3ef40be49b","https://git.kernel.org/stable/c/a1f57a0127b89a6b6620514564aa7eaec16d9af3","https://git.kernel.org/stable/c/b8cfb7c819dd39965136a66fe3a7fde688d976fc","https://git.kernel.org/stable/c/dadbb5d29d6c5f571a50272fce8c1505a9559487"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26718 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dm-crypt, dm-verity: disable tasklets Tasklets have an inherent problem with memory corruption. The function tasklet_action_common calls tasklet_trylock, then it calls the tasklet callback and then it calls tasklet_unlock. If the tasklet callback frees the structure that contains the tasklet or if it calls some code that may free it, tasklet_unlock will write into free memory. The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, but it is not a sufficient fix and the data corruption can still happen [1]. There is no fix for dm-verity and dm-verity will write into free memory with every tasklet-processed bio. There will be atomic workqueues implemented in the kernel 6.9 [2]. They will have better interface and they will not suffer from the memory corruption problem. But we need something that stops the memory corruption now and that can be backported to the stable kernels. So, I'm proposing this commit that disables tasklets in both dm-crypt and dm-verity. This commit doesn't remove the tasklet support, because the tasklet code will be reused when atomic workqueues will be implemented. [1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/ [2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/ | ["https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189","https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257","https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94","https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc","https://git.kernel.org/stable/c/b825e0f9d68c178072bffd32dd34c39e3d2d597a","https://git.kernel.org/stable/c/0a9bab391e336489169b95cb0d4553d921302189","https://git.kernel.org/stable/c/0c45a20cbe68bc4d681734f5c03891124a274257","https://git.kernel.org/stable/c/30884a44e0cedc3dfda8c22432f3ba4078ec2d94","https://git.kernel.org/stable/c/5735a2671ffb70ea29ca83969fe01316ee2ed6fc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26591 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix re-attachment branch in bpf_tracing_prog_attach The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. | ["https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b","https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0","https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee","https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c","https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653","https://git.kernel.org/stable/c/50ae82f080cf87e84828f066c31723b781d68f5b","https://git.kernel.org/stable/c/6cc9c0af0aa06f781fa515a1734b1a4239dfd2c0","https://git.kernel.org/stable/c/715d82ba636cb3629a6e18a33bb9dbe53f9936ee","https://git.kernel.org/stable/c/8c8bcd45e9b10eef12321f08d2e5be33d615509c","https://git.kernel.org/stable/c/a7b98aa10f895e2569403896f2d19b73b6c95653"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-50211 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. | ["https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e","https://git.kernel.org/stable/c/b22d9a5698abf04341f8fbc30141e0673863c3a6","https://git.kernel.org/stable/c/c226964ec786f3797ed389a16392ce4357697d24"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: pvrusb2: fix uaf in pvr2_context_set_notify [Syzbot reported] BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26 CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: usb_hub_wq hub_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272 Freed by task 906: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kfree+0x105/0x340 mm/slub.c:4409 pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline] pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158 [Analyze] Task A set disconnect_flag = !0, which resulted in Task B's condition being met and releasing mp, leading to this issue. [Fix] Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect() to avoid this issue. | ["https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee","https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475","https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a","https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592","https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f","https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb","https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16","https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7","https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c","https://git.kernel.org/stable/c/0a0b79ea55de8514e1750884e5fec77f9fdd01ee","https://git.kernel.org/stable/c/3a1ec89708d2e57e2712f46241282961b1a7a475","https://git.kernel.org/stable/c/40cd818fae875c424a8335009db33c7b5a07de3a","https://git.kernel.org/stable/c/8e60b99f6b7ccb3badeb512f5eb613ad45904592","https://git.kernel.org/stable/c/ab896d93fd6a2cd1afeb034c3cc9226cb499209f","https://git.kernel.org/stable/c/d29ed08964cec8b9729bc55c7bb23f679d7a18fb","https://git.kernel.org/stable/c/eaa410e05bdf562c90b23cdf2d9327f9c4625e16","https://git.kernel.org/stable/c/eb6e9dce979c08210ff7249e5e0eceb8991bfcd7","https://git.kernel.org/stable/c/ed8000e1e8e9684ab6c30cf2b526c0cea039929c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3635 | High | fixed |
|
A vulnerability, which was classified as critical, has been found in Linux Kernel. Affected by this issue is the function tst_timer of the file drivers/atm/idt77252.c of the component IPsec. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. VDB-211934 is the identifier assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211934","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=3f4093e2bf4673f218c0bf17d8362337c400e77b","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://vuldb.com/?id.211934"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3633 | Low | N/A | A vulnerability classified as problematic has been found in Linux Kernel. Affected is the function j1939_session_destroy of the file net/can/j1939/transport.c. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211932. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=8c21c54a53ab21842f5050fa090f26b03c0313d6","https://vuldb.com/?ctiid.211932","https://vuldb.com/?id.211932","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=8c21c54a53ab21842f5050fa090f26b03c0313d6","https://vuldb.com/?ctiid.211932","https://vuldb.com/?id.211932"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0264 | Medium | fixed |
|
A vulnerability was found in the Linux kernel's eBPF verifier when handling internal data structures. Internal memory locations could be returned to userspace. A local attacker with the permissions to insert eBPF code to the kernel can use this to leak internal kernel memory details defeating some of the exploit mitigations in place for the kernel. This flaws affects kernel versions < v5.16-rc6 | ["https://bugzilla.redhat.com/show_bug.cgi?id=2041547","https://bugzilla.redhat.com/show_bug.cgi?id=2041547"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-47745 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] | ["https://git.kernel.org/stable/c/0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1","https://git.kernel.org/stable/c/3393fddbfa947c8e1fdcc4509226905ffffd8b89","https://git.kernel.org/stable/c/49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178","https://git.kernel.org/stable/c/ce14f38d6ee9e88e37ec28427b4b93a7c33c70d3","https://git.kernel.org/stable/c/ea7e2d5e49c05e5db1922387b09ca74aa40f46e2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3812 | High | fixed |
|
An out-of-bounds memory access flaw was found in the Linux kernel’s TUN/TAP device driver functionality in how a user generates a malicious (too big) networking packet when napi frags is enabled. This flaw allows a local user to crash or potentially escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2023:6799","https://access.redhat.com/errata/RHSA-2023:6813","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:1961","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-3812","https://bugzilla.redhat.com/show_bug.cgi?id=2224048","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0","https://access.redhat.com/errata/RHSA-2023:6799","https://access.redhat.com/errata/RHSA-2023:6813","https://access.redhat.com/errata/RHSA-2023:7370","https://access.redhat.com/errata/RHSA-2023:7379","https://access.redhat.com/errata/RHSA-2023:7382","https://access.redhat.com/errata/RHSA-2023:7389","https://access.redhat.com/errata/RHSA-2023:7411","https://access.redhat.com/errata/RHSA-2023:7418","https://access.redhat.com/errata/RHSA-2023:7548","https://access.redhat.com/errata/RHSA-2023:7549","https://access.redhat.com/errata/RHSA-2023:7554","https://access.redhat.com/errata/RHSA-2024:0340","https://access.redhat.com/errata/RHSA-2024:0378","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/errata/RHSA-2024:0554","https://access.redhat.com/errata/RHSA-2024:0562","https://access.redhat.com/errata/RHSA-2024:0563","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0593","https://access.redhat.com/errata/RHSA-2024:1961","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-3812","https://bugzilla.redhat.com/show_bug.cgi?id=2224048","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46794 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix data leak in mmio_read() The mmio_read() function makes a TDVMCALL to retrieve MMIO data for an address from the VMM. Sean noticed that mmio_read() unintentionally exposes the value of an initialized variable (val) on the stack to the VMM. This variable is only needed as an output value. It did not need to be passed to the VMM in the first place. Do not send the original value of *val to the VMM. [ dhansen: clarify what 'val' is used for. ] | ["https://git.kernel.org/stable/c/26c6af49d26ffc377e392e30d4086db19eed0ef7","https://git.kernel.org/stable/c/b55ce742afcb8e8189d82f2f1e635ba1b5a461fa","https://git.kernel.org/stable/c/b6fb565a2d15277896583d471b21bc14a0c99661","https://git.kernel.org/stable/c/ef00818c50cf55a3a56bd9a9fae867c92dfb84e7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-7042 | Medium | fixed |
|
A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service. | ["https://access.redhat.com/security/cve/CVE-2023-7042","https://bugzilla.redhat.com/show_bug.cgi?id=2255497","https://patchwork.kernel.org/project/linux-wireless/patch/20231208043433.271449-1-hdthky0@gmail.com/","https://access.redhat.com/security/cve/CVE-2023-7042","https://bugzilla.redhat.com/show_bug.cgi?id=2255497","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/54PLF5J33IRSLSR4UU6LQSMXX6FI5AOQ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/C25BK2YH5MZ6VNQXKF2NAJBTGXVEPKGC/","https://patchwork.kernel.org/project/linux-wireless/patch/20231208043433.271449-1-hdthky0@gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3773 | Medium | N/A | A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to cause a 4 byte out-of-bounds read of XFRMA_MTIMER_THRESH when parsing netlink attributes, leading to potential leakage of sensitive heap data to userspace. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3773","https://bugzilla.redhat.com/show_bug.cgi?id=2218944","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-3773","https://bugzilla.redhat.com/show_bug.cgi?id=2218944","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6915 | Medium | fixed |
|
A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6915","https://bugzilla.redhat.com/show_bug.cgi?id=2254982","https://github.com/torvalds/linux/commit/af73483f4e8b6f5c68c9aa63257bdd929a9c194a","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6915","https://bugzilla.redhat.com/show_bug.cgi?id=2254982","https://github.com/torvalds/linux/commit/af73483f4e8b6f5c68c9aa63257bdd929a9c194a","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2019-3887 | Medium | N/A | A flaw was found in the way KVM hypervisor handled x2APIC Machine Specific Rregister (MSR) access with nested(=1) virtualization enabled. In that, L1 guest could access L0's APIC register values via L2 guest, when 'virtualize x2APIC mode' is enabled. A guest could use this flaw to potentially crash the host kernel resulting in DoS issue. Kernel versions from 4.16 and newer are vulnerable to this issue. | ["http://www.securityfocus.com/bid/107850","https://access.redhat.com/errata/RHSA-2019:2703","https://access.redhat.com/errata/RHSA-2019:2741","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3887","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IWPOIII2L73HV5PGXSGMRMKQIK47UIYE/","https://usn.ubuntu.com/3979-1/","https://usn.ubuntu.com/3980-1/","https://usn.ubuntu.com/3980-2/","http://www.securityfocus.com/bid/107850","https://access.redhat.com/errata/RHSA-2019:2703","https://access.redhat.com/errata/RHSA-2019:2741","https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3887","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/IWPOIII2L73HV5PGXSGMRMKQIK47UIYE/","https://usn.ubuntu.com/3979-1/","https://usn.ubuntu.com/3980-1/","https://usn.ubuntu.com/3980-2/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-4002 | Medium | fixed |
|
A memory leak flaw in the Linux kernel's hugetlbfs memory usage was found in the way the user maps some regions of memory twice using shmget() which are aligned to PUD alignment with the fault of some of the memory pages. A local user could use this flaw to get unauthorized access to some data. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2025726","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13e4ad2ce8df6e058ef482a31fdd81c725b0f7ea","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4a118f2eead1d6c49e00765de89878288d4b890","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5096","https://www.openwall.com/lists/oss-security/2021/11/25/1","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=2025726","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13e4ad2ce8df6e058ef482a31fdd81c725b0f7ea","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4a118f2eead1d6c49e00765de89878288d4b890","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://www.debian.org/security/2022/dsa-5096","https://www.openwall.com/lists/oss-security/2021/11/25/1","https://www.oracle.com/security-alerts/cpujul2022.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2513 | Medium | N/A | A use-after-free vulnerability was found in the Linux kernel's ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2193097","https://github.com/torvalds/linux/commit/67d7d8ad99be","https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2193097","https://github.com/torvalds/linux/commit/67d7d8ad99be","https://lore.kernel.org/all/20220616021358.2504451-1-libaokun1%40huawei.com/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26586 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b | ["https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62","https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15","https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706","https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182","https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819","https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383","https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62","https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15","https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706","https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182","https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819","https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52504 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 ... __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() ... On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ] | ["https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae","https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1","https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b","https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e","https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4","https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61","https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc","https://git.kernel.org/stable/c/3719d3c36aa853d5a2401af9f8d6b116c91ad5ae","https://git.kernel.org/stable/c/3770c38cd6a60494da29ac2da73ff8156440a2d1","https://git.kernel.org/stable/c/5b784489c8158518bf7a466bb3cc045b0fb66b4b","https://git.kernel.org/stable/c/6788b10620ca6e98575d1e06e72a8974aad7657e","https://git.kernel.org/stable/c/cd287cc208dfe6bd6da98e7f88e723209242c9b4","https://git.kernel.org/stable/c/d35652a5fc9944784f6f50a5c979518ff8dacf61","https://git.kernel.org/stable/c/ecba5afe86f30605eb9dfb7f265a8de0218d4cfc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3567 | High | fixed |
|
A use-after-free flaw was found in vcs_read in drivers/tty/vt/vc_screen.c in vc_screen in the Linux Kernel. This issue may allow an attacker with local user access to cause a system crash or leak internal kernel information. | ["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-3567","https://bugzilla.redhat.com/show_bug.cgi?id=2221463","https://www.spinics.net/lists/stable-commits/msg285184.html","http://packetstormsecurity.com/files/175072/Kernel-Live-Patch-Security-Notice-LSN-0098-1.html","http://packetstormsecurity.com/files/175963/Kernel-Live-Patch-Security-Notice-LSN-0099-1.html","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0431","https://access.redhat.com/errata/RHSA-2024:0432","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-3567","https://bugzilla.redhat.com/show_bug.cgi?id=2221463","https://www.spinics.net/lists/stable-commits/msg285184.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26597 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix global oob in rmnet_policy The variable rmnet_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below: ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK> The buggy address belongs to the variable: rmnet_policy+0x30/0xe0 The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here. | ["https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5","https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590","https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1","https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447","https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468","https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc","https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c","https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534","https://git.kernel.org/stable/c/02467ab8b404d80429107588e0f3425cf5fcd2e5","https://git.kernel.org/stable/c/093dab655808207f7a9f54cf156240aeafc70590","https://git.kernel.org/stable/c/17d06a5c44d8fd2e8e61bac295b09153496f87e1","https://git.kernel.org/stable/c/2295c22348faf795e1ccdf618f6eb7afdb2f7447","https://git.kernel.org/stable/c/3b5254862258b595662a0ccca6e9eeb88d6e7468","https://git.kernel.org/stable/c/b33fb5b801c6db408b774a68e7c8722796b59ecc","https://git.kernel.org/stable/c/c4734535034672f59f2652e1e0058c490da62a5c","https://git.kernel.org/stable/c/ee1dc3bf86f2df777038506b139371a9add02534","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-33288 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 6.2.9. A use-after-free was found in bq24190_remove in drivers/power/supply/bq24190_charger.c. It could allow a local attacker to crash the system due to a race condition. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4","https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4","https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/","https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=47c29d69212911f50bdcdd0564b5999a559010d4","https://github.com/torvalds/linux/commit/47c29d69212911f50bdcdd0564b5999a559010d4","https://lore.kernel.org/all/CAHk-=whcaHLNpb7Mu_QX7ABwPgyRyfW-V8=v4Mv0S22fpjY4JQ%40mail.gmail.com/","https://lore.kernel.org/lkml/20230309174728.233732-1-zyytlz.wz%40163.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-53020 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: l2tp: close all race conditions in l2tp_tunnel_register() The code in l2tp_tunnel_register() is racy in several ways: 1. It modifies the tunnel socket _after_ publishing it. 2. It calls setup_udp_tunnel_sock() on an existing socket without locking. 3. It changes sock lock class on fly, which triggers many syzbot reports. This patch amends all of them by moving socket initialization code before publishing and under sock lock. As suggested by Jakub, the l2tp lockdep class is not necessary as we can just switch to bh_lock_sock_nested(). | ["https://git.kernel.org/stable/c/0b2c59720e65885a394a017d0cf9cab118914682","https://git.kernel.org/stable/c/2d77e5c0ad79004b5ef901895437e9cce6dfcc7e","https://git.kernel.org/stable/c/77e8ed776cdb1a24b2aab8fe7c6f1f154235e1ce","https://git.kernel.org/stable/c/cef0845b6dcfa2f6c2c832e7f9622551456c741d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52589 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: media: rkisp1: Fix IRQ disable race issue In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup. | ["https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7","https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395","https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe","https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545","https://git.kernel.org/stable/c/7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7","https://git.kernel.org/stable/c/870565f063a58576e8a4529f122cac4325c6b395","https://git.kernel.org/stable/c/bf808f58681cab64c81cd814551814fd34e540fe","https://git.kernel.org/stable/c/fab483438342984f2a315fe13c882a80f0f7e545"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52639 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap = gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private = vcpu->kvm; Let children inherit the private field of the parent. | ["https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082","https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc","https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380","https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32","https://git.kernel.org/stable/c/28bb27824f25f36e5f80229a358d66ee09244082","https://git.kernel.org/stable/c/5df3b81a567eb565029563f26f374ae3803a1dfc","https://git.kernel.org/stable/c/f5572c0323cf8b4f1f0618178648a25b8fb8a380","https://git.kernel.org/stable/c/fe752331d4b361d43cfd0b89534b4b2176057c32"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0590 | Medium | fixed |
|
A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem. This flaw leads to a denial of service issue. If patch ebda44da44f6 ("net: sched: fix race condition in qdisc_graft()") not applied yet, then kernel could be affected. | ["https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lore.kernel.org/all/20221018203258.2793282-1-edumazet%40google.com/","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lore.kernel.org/all/20221018203258.2793282-1-edumazet%40google.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52443 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed profile name is empty When processing a packed profile in unpack_profile() described like "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}" a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside. AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace. Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org). | ["https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4","https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf","https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200","https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203","https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87","https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e","https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e","https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45","https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4","https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf","https://git.kernel.org/stable/c/55a8210c9e7d21ff2644809699765796d4bfb200","https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203","https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87","https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af489196953dc4a0e","https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e","https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-46805 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix the waring dereferencing hive Check the amdgpu_hive_info *hive that maybe is NULL. | ["https://git.kernel.org/stable/c/01cd55b971131b07b7ff8d622fa93bb4f8be07df","https://git.kernel.org/stable/c/1940708ccf5aff76de4e0b399f99267c93a89193","https://git.kernel.org/stable/c/4ab720b6aa1ef5e71db1e534b5b45c80ac4ec58a","https://git.kernel.org/stable/c/d3f927ef0607b3c8c3f79ab6d9a4ebead3e35f4c","https://git.kernel.org/stable/c/f20d1d5cbb39802f68be24458861094f3e66f356"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2430 | Medium | fixed |
|
A vulnerability was found due to missing lock for IOPOLL flaw in io_cqring_event_overflow() in io_uring.c in Linux Kernel. This flaw allows a local attacker with user privilege to trigger a Denial of Service threat. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8","https://www.debian.org/security/2023/dsa-5492","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12d7a46f65ae4b7d58a5e0c1cbfa825cf8","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-28328 | Medium | fixed |
|
A NULL pointer dereference flaw was found in the az6027 driver in drivers/media/usb/dev-usb/az6027.c in the Linux Kernel. The message from user space is not checked properly before transferring into the device. This flaw allows a local user to crash the system or potentially cause a denial of service. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2177389","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://bugzilla.redhat.com/show_bug.cgi?id=2177389","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26643 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path. Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout"). Fix this by setting on the dead flag for anonymous sets to skip async gc in this case. According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too. | ["https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363","https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163","https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8","https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36","https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1","https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033","https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c","https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf","https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363","https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163","https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8","https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36","https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1","https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033","https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c","https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4132 | Medium | N/A | A use-after-free vulnerability was found in the siano smsusb module in the Linux kernel. The bug occurs during device initialization when the siano device is plugged in. This flaw allows a local user to crash the system, causing a denial of service condition. | ["https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/security/cve/CVE-2023-4132","https://bugzilla.redhat.com/show_bug.cgi?id=2221707","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/errata/RHSA-2024:0724","https://access.redhat.com/security/cve/CVE-2023-4132","https://bugzilla.redhat.com/show_bug.cgi?id=2221707","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20231020-0005/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26642 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this. Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work. | ["https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1","https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a","https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199","https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7","https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12","https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9","https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f","https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351","https://git.kernel.org/stable/c/16603605b667b70da974bea8216c93e7db043bf1","https://git.kernel.org/stable/c/72c1efe3f247a581667b7d368fff3bd9a03cd57a","https://git.kernel.org/stable/c/7cdc1be24cc1bcd56a3e89ac4aef20e31ad09199","https://git.kernel.org/stable/c/8e07c16695583a66e81f67ce4c46e94dece47ba7","https://git.kernel.org/stable/c/c0c2176d1814b92ea4c8e7eb7c9cd94cd99c1b12","https://git.kernel.org/stable/c/e4988d8415bd0294d6f9f4a1e7095f8b50a97ca9","https://git.kernel.org/stable/c/e9a0d3f376eb356d54ffce36e7cc37514cbfbd6f","https://git.kernel.org/stable/c/fe40ffbca19dc70d7c6b1e3c77b9ccb404c57351","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26853 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: igc: avoid returning frame twice in XDP_REDIRECT When a frame can not be transmitted in XDP_REDIRECT (e.g. due to a full queue), it is necessary to free it by calling xdp_return_frame_rx_napi. However, this is the responsibility of the caller of the ndo_xdp_xmit (see for example bq_xmit_all in kernel/bpf/devmap.c) and thus calling it inside igc_xdp_xmit (which is the ndo_xdp_xmit of the igc driver) as well will lead to memory corruption. In fact, bq_xmit_all expects that it can return all frames after the last successfully transmitted one. Therefore, break for the first not transmitted frame, but do not call xdp_return_frame_rx_napi in igc_xdp_xmit. This is equally implemented in other Intel drivers such as the igb. There are two alternatives to this that were rejected: 1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets). 2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped. The memory corruption can be reproduced with the following script which leads to a kernel panic after a few seconds. It basically generates more traffic than a i225 NIC can transmit and pushes it via XDP_REDIRECT from a virtual interface to the physical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp | ["https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f","https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2","https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a","https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b","https://git.kernel.org/stable/c/1b3b8231386a572bac8cd5b6fd7e944b84f9bb1f","https://git.kernel.org/stable/c/63a3c1f3c9ecc654d851e7906d05334cd0c236e2","https://git.kernel.org/stable/c/8df393af9e7e8dfd62e9c41dbaa4d2ff53bf794a","https://git.kernel.org/stable/c/ef27f655b438bed4c83680e4f01e1cde2739854b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1074 | Medium | N/A | A memory leak flaw was found in the Linux kernel's Stream Control Transmission Protocol. This issue may occur when a user starts a malicious networking service and someone connects to this service. This could allow a local user to starve resources, causing a denial of service. | ["http://www.openwall.com/lists/oss-security/2023/11/05/4","https://bugzilla.redhat.com/show_bug.cgi?id=2173430","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/oss-security/2023/01/23/1","http://www.openwall.com/lists/oss-security/2023/11/05/4","https://bugzilla.redhat.com/show_bug.cgi?id=2173430","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569f","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.openwall.com/lists/oss-security/2023/01/23/1"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26680 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: atlantic: Fix DMA mapping for PTP hwts ring Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes for PTP HWTS ring but then generic aq_ring_free() does not take this into account. Create and use a specific function to free HWTS ring to fix this issue. Trace: [ 215.351607] ------------[ cut here ]------------ [ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes] [ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360 ... [ 215.581176] Call Trace: [ 215.583632] <TASK> [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df [ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df [ 215.594497] ? debug_dma_free_coherent+0x196/0x210 [ 215.599305] ? check_unmap+0xa6f/0x2360 [ 215.603147] ? __warn+0xca/0x1d0 [ 215.606391] ? check_unmap+0xa6f/0x2360 [ 215.610237] ? report_bug+0x1ef/0x370 [ 215.613921] ? handle_bug+0x3c/0x70 [ 215.617423] ? exc_invalid_op+0x14/0x50 [ 215.621269] ? asm_exc_invalid_op+0x16/0x20 [ 215.625480] ? check_unmap+0xa6f/0x2360 [ 215.629331] ? mark_lock.part.0+0xca/0xa40 [ 215.633445] debug_dma_free_coherent+0x196/0x210 [ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10 [ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0 [ 215.648060] dma_free_attrs+0x6d/0x130 [ 215.651834] aq_ring_free+0x193/0x290 [atlantic] [ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic] ... [ 216.127540] ---[ end trace 6467e5964dd2640b ]--- [ 216.132160] DMA-API: Mapped at: [ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0 [ 216.132165] dma_alloc_attrs+0xf5/0x1b0 [ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic] [ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic] [ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic] | ["https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56","https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887","https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12","https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1","https://git.kernel.org/stable/c/004fe5b7f59286a926a45e0cafc7870e9cdddd56","https://git.kernel.org/stable/c/2e7d3b67630dfd8f178c41fa2217aa00e79a5887","https://git.kernel.org/stable/c/466ceebe48cbba3f4506f165fca7111f9eb8bb12","https://git.kernel.org/stable/c/e42e334c645575be5432adee224975d4f536fdb1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26893 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in SMC transport cleanup path When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000004 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | Data abort info: | ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 | CM = 0, WnR = 0, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. | ["https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4","https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c","https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773","https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d","https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd","https://git.kernel.org/stable/c/0d276d9f335f41d6524258d58c0c0241ef9a83a4","https://git.kernel.org/stable/c/857f56db8c3a71f9871922b6984ff74ad588cb2c","https://git.kernel.org/stable/c/8ffaa17ccb1eb1b65cf85db63225a3581c303773","https://git.kernel.org/stable/c/ead445dd3d681020af333649a27306160eee761d","https://git.kernel.org/stable/c/f1d71576d2c9ec8fdb822173fa7f3de79475e9bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26696 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. | ["https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e","https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534","https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f","https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32","https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46","https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6","https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d","https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28","https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e","https://git.kernel.org/stable/c/38296afe3c6ee07319e01bb249aa4bb47c07b534","https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f","https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32","https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46","https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6","https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca54475c34f7d","https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26737 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel The following race is possible between bpf_timer_cancel_and_free and bpf_timer_cancel. It will lead a UAF on the timer->timer. bpf_timer_cancel(); spin_lock(); t = timer->time; spin_unlock(); bpf_timer_cancel_and_free(); spin_lock(); t = timer->timer; timer->timer = NULL; spin_unlock(); hrtimer_cancel(&t->timer); kfree(t); /* UAF on t */ hrtimer_cancel(&t->timer); In bpf_timer_cancel_and_free, this patch frees the timer->timer after a rcu grace period. This requires a rcu_head addition to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init, this does not need a kfree_rcu because it is still under the spin_lock and timer->timer has not been visible by others yet. In bpf_timer_cancel, rcu_read_lock() is added because this helper can be used in a non rcu critical section context (e.g. from a sleepable bpf prog). Other timer->timer usages in helpers.c have been audited, bpf_timer_cancel() is the only place where timer->timer is used outside of the spin_lock. Another solution considered is to mark a t->flag in bpf_timer_cancel and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free, it busy waits for the flag to be cleared before kfree(t). This patch goes with a straight forward solution and frees timer->timer after a rcu grace period. | ["https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f","https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c","https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33","https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6","https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5","https://git.kernel.org/stable/c/0281b919e175bb9c3128bd3872ac2903e9436e3f","https://git.kernel.org/stable/c/5268bb02107b9eedfdcd51db75b407d10043368c","https://git.kernel.org/stable/c/7d80a9e745fa5b47da3bca001f186c02485c7c33","https://git.kernel.org/stable/c/8327ed12e8ebc5436bfaa1786c49988894f9c8a6","https://git.kernel.org/stable/c/addf5e297e6cbf5341f9c07720693ca9ba0057b5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6039 | Medium | fixed |
|
A use-after-free flaw was found in lan78xx_disconnect in drivers/net/usb/lan78xx.c in the network sub-component, net/usb/lan78xx in the Linux Kernel. This flaw allows a local attacker to crash the system when the LAN78XX USB device detaches. | ["https://access.redhat.com/security/cve/CVE-2023-6039","https://bugzilla.redhat.com/show_bug.cgi?id=2248755","https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3","https://access.redhat.com/security/cve/CVE-2023-6039","https://bugzilla.redhat.com/show_bug.cgi?id=2248755","https://github.com/torvalds/linux/commit/1e7417c188d0a83fb385ba2dbe35fd2563f2b6f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26866 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: lpspi: Avoid potential use-after-free in probe() fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork | ["https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f","https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861","https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68","https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea","https://git.kernel.org/stable/c/1543418e82789cc383cd36d41469983c64e3fc7f","https://git.kernel.org/stable/c/2ae0ab0143fcc06190713ed81a6486ed0ad3c861","https://git.kernel.org/stable/c/996ce839606afd0fef91355627868022aa73eb68","https://git.kernel.org/stable/c/da83ed350e4604b976e94239b08d8e2e7eaee7ea"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26686 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children stats lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call do_task_stat() at the same time and the process has NR_THREADS, it will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change do_task_stat() to use sig->stats_lock to gather the statistics outside of ->siglock protected section, in the likely case this code will run lockless. | ["https://git.kernel.org/stable/c/0c35d1914353799c54fa1843fe7dea6fcbcdbac5","https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071","https://git.kernel.org/stable/c/3820b0fac7732a653bcc6f6ac20c1d72e697f8f6","https://git.kernel.org/stable/c/4fe85bdaabd63f8f8579b24a10ed597c9c482164","https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305","https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d","https://git.kernel.org/stable/c/27978243f165b44e342f28f449b91327944ea071","https://git.kernel.org/stable/c/7601df8031fd67310af891897ef6cc0df4209305","https://git.kernel.org/stable/c/cf4b8c39b9a0bd81c47afc7ef62914a62dd5ec4d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26835 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: set dormant flag on hook register failure We need to set the dormant flag again if we fail to register the hooks. During memory pressure hook registration can fail and we end up with a table marked as active but no registered hooks. On table/base chain deletion, nf_tables will attempt to unregister the hook again which yields a warn splat from the nftables core. | ["https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376","https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af","https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be","https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95","https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7","https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3","https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec","https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069","https://git.kernel.org/stable/c/0c9302a6da262e6ab6a6c1d30f04a6130ed97376","https://git.kernel.org/stable/c/31ea574aeca1aa488e18716459bde057217637af","https://git.kernel.org/stable/c/664264a5c55bf97a9c571c557d477b75416199be","https://git.kernel.org/stable/c/6f2496366426cec18ba53f1c7f6c3ac307ca6a95","https://git.kernel.org/stable/c/a6411f3c48f991c19aaf9a24fce36865fbba28d7","https://git.kernel.org/stable/c/ae4360cbd385f0d7a8a86d5723e50448cc6318f3","https://git.kernel.org/stable/c/bccebf64701735533c8db37773eeacc6566cc8ec","https://git.kernel.org/stable/c/f2135bbf14949687e96cabb13d8a91ae3deb9069","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52456 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND. | ["https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06","https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda","https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181","https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0","https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b","https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19","https://git.kernel.org/stable/c/63ee7be01a3f7d28b1ea8b8d7944f12bb7b0ed06","https://git.kernel.org/stable/c/6e04a9d30509fb53ba6df5d655ed61d607a7cfda","https://git.kernel.org/stable/c/763cd68746317b5d746dc2649a3295c1efb41181","https://git.kernel.org/stable/c/78d60dae9a0c9f09aa3d6477c94047df2fe6f7b0","https://git.kernel.org/stable/c/9a662d06c22ddfa371958c2071dc350436be802b","https://git.kernel.org/stable/c/ff168d4fdb0e1ba35fb413a749b3d6cce918ec19","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52625 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Refactor DMCUB enter/exit idle interface [Why] We can hang in place trying to send commands when the DMCUB isn't powered on. [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself. Fixing this issue involves the following: 1. Using a software state to track whether or not we need to start the process to exit idle or notify idle. It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all. 2. Refactor any instances of exit/notify idle to use a single wrapper that maintains this SW state. This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop. 3. Make sure we exit out of idle prior to sending any commands or waiting for DMCUB idle. This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface. | ["https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f","https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa","https://git.kernel.org/stable/c/820c3870c491946a78950cdf961bf40e28c1025f","https://git.kernel.org/stable/c/8e57c06bf4b0f51a4d6958e15e1a99c9520d00fa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-49875 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30 | ["https://git.kernel.org/stable/c/0ea4333c679f333e23956de743ad17387819d3f2","https://git.kernel.org/stable/c/340e61e44c1d2a15c42ec72ade9195ad525fd048","https://git.kernel.org/stable/c/6fe058502f8864649c3d614b06b2235223798f48","https://git.kernel.org/stable/c/825789ca94602543101045ad3aad19b2b60c6b2a","https://git.kernel.org/stable/c/c76005adfa93d1a027433331252422078750321f","https://git.kernel.org/stable/c/e9cfecca22a36b927a440abc6307efb9e138fed5","https://git.kernel.org/stable/c/f7d8ee9db94372b8235f5f22bb24381891594c42"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26759 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/swap: fix race when skipping swapcache When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads swapin the same entry at the same time, they get different pages (A, B). Before one thread (T0) finishes the swapin and installs page (A) to the PTE, another thread (T1) could finish swapin of page (B), swap_free the entry, then swap out the possibly modified page reusing the same entry. It breaks the pte_same check in (T0) because PTE value is unchanged, causing ABA problem. Thread (T0) will install a stalled page (A) into the PTE and cause data corruption. One possible callstack is like this: CPU0 CPU1 ---- ---- do_swap_page() do_swap_page() with same entry <direct swapin path> <direct swapin path> <alloc page A> <alloc page B> swap_read_folio() <- read to page A swap_read_folio() <- read to page B <slow on later locks or interrupt> <finished swapin first> ... set_pte_at() swap_free() <- entry is free <write to page B, now page A stalled> <swap out page B to same swap entry> pte_same() <- Check pass, PTE seems unchanged, but page A is stalled! swap_free() <- page B content lost! set_pte_at() <- staled page A installed! And besides, for ZRAM, swap_free() allows the swap device to discard the entry content, so even if page (B) is not modified, if swap_read_folio() on CPU0 happens later than swap_free() on CPU1, it may also cause data loss. To fix this, reuse swapcache_prepare which will pin the swap entry using the cache flag, and allow only one thread to swap it in, also prevent any parallel code from putting the entry in the cache. Release the pin after PT unlocked. Racers just loop and wait since it's a rare and very short event. A schedule_timeout_uninterruptible(1) call is added to avoid repeated page faults wasting too much CPU, causing livelock or adding too much noise to perf statistics. A similar livelock issue was described in commit 029c4628b2eb ("mm: swap: get rid of livelock in swapin readahead") Reproducer: This race issue can be triggered easily using a well constructed reproducer and patched brd (with a delay in read path) [1]: With latest 6.8 mainline, race caused data loss can be observed easily: $ gcc -g -lpthread test-thread-swap-race.c && ./a.out Polulating 32MB of memory region... Keep swapping out... Starting round 0... Spawning 65536 workers... 32746 workers spawned, wait for done... Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss! Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss! Round 0 Failed, 15 data loss! This reproducer spawns multiple threads sharing the same memory region using a small swap device. Every two threads updates mapped pages one by one in opposite direction trying to create a race, with one dedicated thread keep swapping out the data out using madvise. The reproducer created a reproduce rate of about once every 5 minutes, so the race should be totally possible in production. After this patch, I ran the reproducer for over a few hundred rounds and no data loss observed. Performance overhead is minimal, microbenchmark swapin 10G from 32G zram: Before: 10934698 us After: 11157121 us Cached: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag) [kasong@tencent.com: v4] | ["https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458","https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95","https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a","https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d","https://git.kernel.org/stable/c/13ddaf26be324a7f951891ecd9ccd04466d27458","https://git.kernel.org/stable/c/2dedda77d4493f3e92e414b272bfa60f1f51ed95","https://git.kernel.org/stable/c/305152314df82b22cf9b181f3dc5fc411002079a","https://git.kernel.org/stable/c/d183a4631acfc7af955c02a02e739cec15f5234d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52516 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don't acquire serial console's port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 ____do_softirq+0x18/0x24 ... -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 ... -> #0 (console_owner){-...}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 ... Chain exists of: console_owner --> &port_lock_key --> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol ---truncated--- | ["https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c","https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab","https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae","https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1","https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3","https://git.kernel.org/stable/c/ac0d068099349cbca3d93f2e3b15bb329364b08c","https://git.kernel.org/stable/c/be8f49029eca3efbad0d74dbff3cb9129994ffab","https://git.kernel.org/stable/c/c79300599923daaa30f417c75555d5566b3d31ae","https://git.kernel.org/stable/c/fb5a4315591dae307a65fc246ca80b5159d296e1","https://git.kernel.org/stable/c/fe2b811a02c3244ebf6059039e4a9e715e26a9e3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6622 | Medium | N/A | A null pointer dereference vulnerability was found in nft_dynset_init() in net/netfilter/nft_dynset.c in nf_tables in the Linux kernel. This issue may allow a local attacker with CAP_NET_ADMIN user privilege to trigger a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6622","https://bugzilla.redhat.com/show_bug.cgi?id=2253632","https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6622","https://bugzilla.redhat.com/show_bug.cgi?id=2253632","https://github.com/torvalds/linux/commit/3701cd390fd731ee7ae8b8006246c8db82c72bea","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AAOVK2F3ALGKYIQ5IOMAYEC2DGI7BWAW/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/G3AGDVE3KBLOOYBPISFDS74R4YAZEDAY/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26647 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()' In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc' was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc' NULL pointer check. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903) | ["https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207","https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c","https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647","https://git.kernel.org/stable/c/3bb9b1f958c3d986ed90a3ff009f1e77e9553207","https://git.kernel.org/stable/c/6aa5ede6665122f4c8abce3c6eba06b49e54d25c","https://git.kernel.org/stable/c/cf656fc7276e5b3709a81bc9d9639459be2b2647"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26714 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: interconnect: qcom: sc8180x: Mark CO0 BCM keepalive The CO0 BCM needs to be up at all times, otherwise some hardware (like the UFS controller) loses its connection to the rest of the SoC, resulting in a hang of the platform, accompanied by a spectacular logspam. Mark it as keepalive to prevent such cases. | ["https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7","https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0","https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0","https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43","https://git.kernel.org/stable/c/6616d3c4f8284a7b3ef978c916566bd240cea1c7","https://git.kernel.org/stable/c/7a3a70dd08e4b7dffc2f86f2c68fc3812804b9d0","https://git.kernel.org/stable/c/85e985a4f46e462a37f1875cb74ed380e7c0c2e0","https://git.kernel.org/stable/c/d8e36ff40cf9dadb135f3a97341c02c9a7afcc43"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49326 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rtl818x: Prevent using not initialized queues Using not existing queues can panic the kernel with rtl8180/rtl8185 cards. Ignore the skb priority for those cards, they only have one tx queue. Pierre Asselin (pa@panix.com) reported the kernel crash in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html He also confirmed that this patch fixes the issue. In summary this happened: After updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a "divide error: 0000" when connecting to an AP. Control port tx now tries to use IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in 2.10. Since only the rtl8187se part of the driver supports QoS, the priority of the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185 cards. rtl8180 is then unconditionally reading out the priority and finally crashes on drivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this patch: idx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries "ring->entries" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got initialized. | ["https://git.kernel.org/stable/c/6ad81ad0cf5744738ce94c8e64051ddd80a1734c","https://git.kernel.org/stable/c/746285cf81dc19502ab238249d75f5990bd2d231","https://git.kernel.org/stable/c/769ec2a824deae2f1268dfda14999a4d14d0d0c5","https://git.kernel.org/stable/c/98e55b0b876bde3353f4e074883d66ecb55c65a3","https://git.kernel.org/stable/c/9ad1981fc4de3afb7db3e8eb5a6a52d4c7d0d577","https://git.kernel.org/stable/c/9d5e96cc1f1720019ce27b127a31695148d38bb0","https://git.kernel.org/stable/c/b5dca2cd3f0239512da808598b4e70557eb4c2a1","https://git.kernel.org/stable/c/b8ce58ab80faaea015c206382041ff3bcf5495ff","https://git.kernel.org/stable/c/d7e30dfc166d33470bba31a42f9bbc346e5409d5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26685 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential bug in end_buffer_async_write According to a syzbot report, end_buffer_async_write(), which handles the completion of block device writes, may detect abnormal condition of the buffer async_write flag and cause a BUG_ON failure when using nilfs2. Nilfs2 itself does not use end_buffer_async_write(). But, the async_write flag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issue with race condition of competition between segments for dirty blocks") as a means of resolving double list insertion of dirty blocks in nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the resulting crash. This modification is safe as long as it is used for file data and b-tree node blocks where the page caches are independent. However, it was irrelevant and redundant to also introduce async_write for segment summary and super root blocks that share buffers with the backing device. This led to the possibility that the BUG_ON check in end_buffer_async_write would fail as described above, if independent writebacks of the backing device occurred in parallel. The use of async_write for segment summary buffers has already been removed in a previous change. Fix this issue by removing the manipulation of the async_write flag for the remaining super root block buffer. | ["https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803","https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b","https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff","https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab","https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8","https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928","https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd","https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596","https://git.kernel.org/stable/c/2c3bdba00283a6c7a5b19481a59a730f46063803","https://git.kernel.org/stable/c/5bc09b397cbf1221f8a8aacb1152650c9195b02b","https://git.kernel.org/stable/c/626daab3811b772086aef1bf8eed3ffe6f523eff","https://git.kernel.org/stable/c/6589f0f72f8edd1fa11adce4eedbd3615f2e78ab","https://git.kernel.org/stable/c/8fa90634ec3e9cc50f42dd605eec60f2d146ced8","https://git.kernel.org/stable/c/c4a09fdac625e64abe478dcf88bfa20406616928","https://git.kernel.org/stable/c/d31c8721e816eff5ca6573cc487754f357c093cd","https://git.kernel.org/stable/c/f3e4963566f58726d3265a727116a42b591f6596","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26677 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix delayed ACKs to not set the reference serial number Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference. | ["https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2","https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae","https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef","https://git.kernel.org/stable/c/200cb50b9e154434470c8969d32474d38475acc2","https://git.kernel.org/stable/c/63719f490e6a89896e9a463d2b45e8203eab23ae","https://git.kernel.org/stable/c/e7870cf13d20f56bfc19f9c3e89707c69cf104ef"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26646 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: thermal: intel: hfi: Add syscore callbacks for system-wide PM The kernel allocates a memory buffer and provides its location to the hardware, which uses it to update the HFI table. This allocation occurs during boot and remains constant throughout runtime. When resuming from hibernation, the restore kernel allocates a second memory buffer and reprograms the HFI hardware with the new location as part of a normal boot. The location of the second memory buffer may differ from the one allocated by the image kernel. When the restore kernel transfers control to the image kernel, its HFI buffer becomes invalid, potentially leading to memory corruption if the hardware writes to it (the hardware continues to use the buffer from the restore kernel). It is also possible that the hardware "forgets" the address of the memory buffer when resuming from "deep" suspend. Memory corruption may also occur in such a scenario. To prevent the described memory corruption, disable HFI when preparing to suspend or hibernate. Enable it when resuming. Add syscore callbacks to handle the package of the boot CPU (packages of non-boot CPUs are handled via CPU offline). Syscore ops always run on the boot CPU. Additionally, HFI only needs to be disabled during "deep" suspend and hibernation. Syscore ops only run in these cases. [ rjw: Comment adjustment, subject and changelog edits ] | ["https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee","https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566","https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9","https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c","https://git.kernel.org/stable/c/019ccc66d56a696a4dfee3bfa2f04d0a7c3d89ee","https://git.kernel.org/stable/c/28f010dc50df0f7987c04112114fcfa7e0803566","https://git.kernel.org/stable/c/97566d09fd02d2ab329774bb89a2cdf2267e86d9","https://git.kernel.org/stable/c/c9d6d63b6c03afaa6f185df249af693a7939577c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52561 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y. | ["https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6","https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2","https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b","https://git.kernel.org/stable/c/110e70fccce4f22b53986ae797d665ffb1950aa6","https://git.kernel.org/stable/c/82dacd0ca0d9640723824026d6fdf773c02de1d2","https://git.kernel.org/stable/c/dc1ab6577475b0460ba4261cd9caec37bd62ca0b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-37453 | Medium | N/A | An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in read_descriptors in drivers/usb/core/sysfs.c. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b","https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/","https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/","https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1e4c574225cc5a0553115e5eb5787d1474db5b0f","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=85d07c55621676d47d873d2749b88f783cd4d5a1","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=de28e469da75359a2bb8cd8778b78aa64b1be1f4","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b","https://lore.kernel.org/all/000000000000c0ffe505fe86c9ca%40google.com/T/","https://lore.kernel.org/all/000000000000e56434059580f86e%40google.com/T/","https://syzkaller.appspot.com/bug?extid=18996170f8096c6174d0"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45888 | Medium | N/A | An issue was discovered in the Linux kernel through 6.0.9. drivers/char/xillybus/xillyusb.c has a race condition and use-after-free during physical removal of a USB device. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920","https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a4b71816b6076029017a7bab3a9dcee12a920","https://lore.kernel.org/all/20221022175404.GA375335%40ubuntu/","https://security.netapp.com/advisory/ntap-20230113-0006/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-26545 | Medium | fixed |
|
In the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230316-0009/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.13","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://github.com/torvalds/linux/commit/fda6c89fe3d9aca073495a664e1d5aea28cd4377","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230316-0009/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26671 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. | ["https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56","https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed","https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0","https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f","https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b","https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676","https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10","https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2","https://git.kernel.org/stable/c/1d9c777d3e70bdc57dddf7a14a80059d65919e56","https://git.kernel.org/stable/c/5266caaf5660529e3da53004b8b7174cab6374ed","https://git.kernel.org/stable/c/6d8b01624a2540336a32be91f25187a433af53a0","https://git.kernel.org/stable/c/7610ba1319253225a9ba8a9d28d472fc883b4e2f","https://git.kernel.org/stable/c/89e0e66682e1538aeeaa3109503473663cd24c8b","https://git.kernel.org/stable/c/9525b38180e2753f0daa1a522b7767a2aa969676","https://git.kernel.org/stable/c/ecd7744a1446eb02ccc63e493e2eb6ede4ef1e10","https://git.kernel.org/stable/c/f1bc0d8163f8ee84a8d5affdf624cfad657df1d2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52609 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: binder: fix race between mmput() and do_exit() Task A calls binder_update_page_range() to allocate and insert pages on a remote address space from Task B. For this, Task A pins the remote mm via mmget_not_zero() first. This can race with Task B do_exit() and the final mmput() refcount decrement will come from Task A. Task A | Task B ------------------+------------------ mmget_not_zero() | | do_exit() | exit_mm() | mmput() mmput() | exit_mmap() | remove_vma() | fput() | In this case, the work of ____fput() from Task B is queued up in Task A as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup work gets executed. However, Task A instead sleep, waiting for a reply from Task B that never comes (it's dead). This means the binder_deferred_release() is blocked until an unrelated binder event forces Task A to go back to userspace. All the associated death notifications will also be delayed until then. In order to fix this use mmput_async() that will schedule the work in the corresponding mm->async_put_work WQ instead of Task A. | ["https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097","https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3","https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e","https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01","https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918","https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608","https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9","https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5","https://git.kernel.org/stable/c/252a2a5569eb9f8d16428872cc24dea1ac0bb097","https://git.kernel.org/stable/c/6696f76c32ff67fec26823fc2df46498e70d9bf3","https://git.kernel.org/stable/c/67f16bf2cc1698fd50e01ee8a2becc5a8e6d3a3e","https://git.kernel.org/stable/c/77d210e8db4d61d43b2d16df66b1ec46fad2ee01","https://git.kernel.org/stable/c/7e7a0d86542b0ea903006d3f42f33c4f7ead6918","https://git.kernel.org/stable/c/95b1d336b0642198b56836b89908d07b9a0c9608","https://git.kernel.org/stable/c/98fee5bee97ad47b527a997d5786410430d1f0e9","https://git.kernel.org/stable/c/9a9ab0d963621d9d12199df9817e66982582d5a5","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1852 | Medium | fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel’s KVM module, which can lead to a denial of service in the x86_emulate_insn in arch/x86/kvm/emulate.c. This flaw occurs while executing an illegal instruction in guest in the Intel CPU. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2089815","https://github.com/torvalds/linux/commit/fee060cd52d69c114b62d1a2948ea9648b5131f9","https://bugzilla.redhat.com/show_bug.cgi?id=2089815","https://github.com/torvalds/linux/commit/fee060cd52d69c114b62d1a2948ea9648b5131f9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1195 | Medium | fixed |
|
A use-after-free vulnerability was found in the Linux kernel in drivers/net/hamradio. This flaw allows a local attacker with a user privilege to cause a denial of service (DOS) when the mkiss or sixpack device is detached and reclaim resources early. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2056381","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b9111922b1f399aba6ed1e1b8f2079c3da1aed8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e0588c291d6ce225f2b891753ca41d45ba42469","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81b1d548d00bcd028303c4f3150fa753b9b8aa71","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f37aead1b82a770c48b5d583f35ec22aabb61e","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://bugzilla.redhat.com/show_bug.cgi?id=2056381","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b9111922b1f399aba6ed1e1b8f2079c3da1aed8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e0588c291d6ce225f2b891753ca41d45ba42469","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81b1d548d00bcd028303c4f3150fa753b9b8aa71","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2f37aead1b82a770c48b5d583f35ec22aabb61e","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-23848 | Medium | N/A | In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c. | ["https://lore.kernel.org/lkml/e9f42704-2f99-4f2c-ade5-f952e5fd53e5%40xs4all.nl/","https://lore.kernel.org/lkml/e9f42704-2f99-4f2c-ade5-f952e5fd53e5%40xs4all.nl/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26659 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: xhci: handle isoc Babble and Buffer Overrun events properly xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. | ["https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c","https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3","https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134","https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e","https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811","https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97","https://git.kernel.org/stable/c/2aa7bcfdbb46241c701811bbc0d64d7884e3346c","https://git.kernel.org/stable/c/2e3ec80ea7ba58bbb210e83b5a0afefee7c171d3","https://git.kernel.org/stable/c/418456c0ce56209610523f21734c5612ee634134","https://git.kernel.org/stable/c/696e4112e5c1ee61996198f0ebb6ca3fab55166e","https://git.kernel.org/stable/c/7c4650ded49e5b88929ecbbb631efb8b0838e811","https://git.kernel.org/stable/c/f5e7ffa9269a448a720e21f1ed1384d118298c97","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52583 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. | ["https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160","https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980","https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67","https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e","https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca","https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085","https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3","https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6","https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160","https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980","https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67","https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e","https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca","https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085","https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3","https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26679 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: inet: read sk->sk_family once in inet_recv_error() inet_recv_error() is called without holding the socket lock. IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM socket option and trigger a KCSAN warning. | ["https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830","https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41","https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2","https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299","https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd","https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b","https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40","https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd","https://git.kernel.org/stable/c/307fa8a75ab7423fa5c73573ec3d192de5027830","https://git.kernel.org/stable/c/3266e638ba5cc1165f5e6989eb8c0720f1cc4b41","https://git.kernel.org/stable/c/4a5e31bdd3c1702b520506d9cf8c41085f75c7f2","https://git.kernel.org/stable/c/54538752216bf89ee88d47ad07802063a498c299","https://git.kernel.org/stable/c/5993f121fbc01dc2d734f0ff2628009b258fb1dd","https://git.kernel.org/stable/c/88081ba415224cf413101def4343d660f56d082b","https://git.kernel.org/stable/c/caa064c3c2394d03e289ebd6b0be5102eb8a5b40","https://git.kernel.org/stable/c/eef00a82c568944f113f2de738156ac591bbd5cd","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26902 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf: RISCV: Fix panic on pmu overflow handler (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042. [ 273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [ 273.320851] Oops [#1] [ 273.323179] Modules linked in: [ 273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [ 273.332521] Hardware name: Sophgo Mango (DT) [ 273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.342291] ra : pmu_sbi_ovf_handler+0x2e0/0x34e [ 273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [ 273.354454] gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [ 273.361815] t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [ 273.369180] s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [ 273.376540] a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [ 273.383901] a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [ 273.391327] s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [ 273.398773] s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [ 273.406139] s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [ 273.413660] s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [ 273.421022] t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [ 273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [ 273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62 [ 273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee [ 273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36 [ 273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e [ 273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74 [ 273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92 [ 273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [ 273.477921] ---[ end trace 0000000000000000 ]--- [ 273.482630] Kernel panic - not syncing: Fatal exception in interrupt | ["https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c","https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9","https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6","https://git.kernel.org/stable/c/34b567868777e9fd39ec5333969728a7f0cf179c","https://git.kernel.org/stable/c/3ede8e94de6b834b48b0643385e66363e7a04be9","https://git.kernel.org/stable/c/9f599ba3b9cc4bdb8ec1e3f0feddd41bf9d296d6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26751 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. | ["https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8","https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482","https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8","https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997","https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa","https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e","https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48","https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557","https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8","https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482","https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8","https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997","https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa","https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e","https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48","https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26675 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K") Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860 | ["https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8","https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16","https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed","https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982","https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3","https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719","https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b","https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8","https://git.kernel.org/stable/c/210d938f963dddc543b07e66a79b7d8d4bd00bd8","https://git.kernel.org/stable/c/4e2c4846b2507f6dfc9bea72b7567c2693a82a16","https://git.kernel.org/stable/c/4fdb14ba89faff6e6969a4dffdc8e54235d6e5ed","https://git.kernel.org/stable/c/56fae81633ccee307cfcb032f706bf1863a56982","https://git.kernel.org/stable/c/58fbe665b097bf7b3144da7e7b91fb27aa8d0ae3","https://git.kernel.org/stable/c/7e5ef49670766c9742ffcd9cead7cdb018268719","https://git.kernel.org/stable/c/b06e067e93fa4b98acfd3a9f38a398ab91bbc58b","https://git.kernel.org/stable/c/cb88cb53badb8aeb3955ad6ce80b07b598e310b8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52500 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response. | ["https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749","https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7","https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4","https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172","https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d","https://git.kernel.org/stable/c/2259e1901b2d8c0e8538fc99e77de443b939e749","https://git.kernel.org/stable/c/22e6d783a33015bcdf0979015e4eac603912bea7","https://git.kernel.org/stable/c/2afd8fcee0c4d65a482e30c3ad2a92c25e5e92d4","https://git.kernel.org/stable/c/c13e7331745852d0dd7c35eabbe181cbd5b01172","https://git.kernel.org/stable/c/d540a4370aba378fbedf349ba0bb68e96e24243d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26758 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore suspended array in md_check_recovery() mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) suspend the array: raid_postsuspend mddev_suspend 2) stop the array: raid_dtr md_stop __md_stop_writes stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 3) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 4) daemon thread can't unregister sync thread: md_check_recovery if (mddev->suspended) return; -> return directly md_read_sync_thread clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery); -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang; This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend. | ["https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757","https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0","https://git.kernel.org/stable/c/1baae052cccd08daf9a9d64c3f959d8cdb689757","https://git.kernel.org/stable/c/a55f0d6179a19c6b982e2dc344d58c98647a3be0"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-25740 | Medium | N/A | A memory leak flaw was found in the UBI driver in drivers/mtd/ubi/attach.c in the Linux kernel through 6.7.4 for UBI_IOCATT, because kobj->name is not released. | ["https://lore.kernel.org/lkml/0171b6cc-95ee-3538-913b-65a391a446b3%40huawei.com/T/","https://lore.kernel.org/lkml/0171b6cc-95ee-3538-913b-65a391a446b3%40huawei.com/T/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3358 | Medium | fixed |
|
A null pointer dereference was found in the Linux kernel's Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b3d40c3ec3dc4ad78017de6c3a38979f57aaaab8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26668 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: reject configurations that cause integer overflow Reject bogus configs where internal token counter wraps around. This only occurs with very very large requests, such as 17gbyte/s. Its better to reject this rather than having incorrect ratelimit. | ["https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a","https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1","https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0","https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b","https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa","https://git.kernel.org/stable/c/00c2c29aa36d1d1827c51a3720e9f893a22c7c6a","https://git.kernel.org/stable/c/79d4efd75e7dbecd855a3b8a63e65f7265f466e1","https://git.kernel.org/stable/c/9882495d02ecc490604f747437a40626dc9160d0","https://git.kernel.org/stable/c/bc6e242bb74e2ae616bfd2b250682b738e781c9b","https://git.kernel.org/stable/c/c9d9eb9c53d37cdebbad56b91e40baf42d5a97aa"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-23000 | Medium | fixed |
|
In the Linux kernel before 5.17, drivers/phy/tegra/xusb.c mishandles the tegra_xusb_find_port_node return value. Callers expect NULL in the error case, but an error pointer is used. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f","https://security.netapp.com/advisory/ntap-20230331-0004/","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17","https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f","https://security.netapp.com/advisory/ntap-20230331-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52638 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change] | ["https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170","https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e","https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284","https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d","https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf","https://git.kernel.org/stable/c/03358aba991668d3bb2c65b3c82aa32c36851170","https://git.kernel.org/stable/c/26dfe112ec2e95fe0099681f6aec33da13c2dd8e","https://git.kernel.org/stable/c/559b6322f9480bff68cfa98d108991e945a4f284","https://git.kernel.org/stable/c/6cdedc18ba7b9dacc36466e27e3267d201948c8d","https://git.kernel.org/stable/c/aedda066d717a0b4335d7e0a00b2e3a61e40afcf"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26733 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> | ["https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a","https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50","https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91","https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667","https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587","https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0","https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a","https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50","https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91","https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667","https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587","https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://security.netapp.com/advisory/ntap-20241101-0013/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-1151 | Medium | N/A | A vulnerability was reported in the Open vSwitch sub-component in the Linux Kernel. The flaw occurs when a recursive operation of code push recursively calls into the code block. The OVS module does not validate the stack depth, pushing too many frames and causing a stack overflow. As a result, this can lead to a crash or other related issues. | ["https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/errata/RHSA-2024:9315","https://access.redhat.com/security/cve/CVE-2024-1151","https://bugzilla.redhat.com/show_bug.cgi?id=2262241","https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2024-1151","https://bugzilla.redhat.com/show_bug.cgi?id=2262241","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3LZROQAX7Q7LEP4F7WQ3KUZKWCZGFFP2/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GS7S3XLTLOUKBXV67LLFZWB3YVFJZHRK/","https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52610 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix skb leak and crash on ooo frags act_ct adds skb->users before defragmentation. If frags arrive in order, the last frag's reference is reset in: inet_frag_reasm_prepare skb_morph which is not straightforward. However when frags arrive out of order, nobody unref the last frag, and all frags are leaked. The situation is even worse, as initiating packet capture can lead to a crash[0] when skb has been cloned and shared at the same time. Fix the issue by removing skb_get() before defragmentation. act_ct returns TC_ACT_CONSUMED when defrag failed or in progress. [0]: [ 843.804823] ------------[ cut here ]------------ [ 843.809659] kernel BUG at net/core/skbuff.c:2091! [ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP [ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2 [ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022 [ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300 [ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89 [ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202 [ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820 [ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00 [ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000 [ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880 [ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900 [ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000 [ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0 [ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 843.894229] PKRU: 55555554 [ 843.898539] Call Trace: [ 843.902772] <IRQ> [ 843.906922] ? __die_body+0x1e/0x60 [ 843.911032] ? die+0x3c/0x60 [ 843.915037] ? do_trap+0xe2/0x110 [ 843.918911] ? pskb_expand_head+0x2ac/0x300 [ 843.922687] ? do_error_trap+0x65/0x80 [ 843.926342] ? pskb_expand_head+0x2ac/0x300 [ 843.929905] ? exc_invalid_op+0x50/0x60 [ 843.933398] ? pskb_expand_head+0x2ac/0x300 [ 843.936835] ? asm_exc_invalid_op+0x1a/0x20 [ 843.940226] ? pskb_expand_head+0x2ac/0x300 [ 843.943580] inet_frag_reasm_prepare+0xd1/0x240 [ 843.946904] ip_defrag+0x5d4/0x870 [ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack] [ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct] [ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred] [ 843.959657] tcf_action_exec+0xa1/0x160 [ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower] [ 843.966010] ? skb_clone+0x53/0xc0 [ 843.969173] tcf_classify+0x24d/0x420 [ 843.972333] tc_run+0x8f/0xf0 [ 843.975465] __netif_receive_skb_core+0x67a/0x1080 [ 843.978634] ? dev_gro_receive+0x249/0x730 [ 843.981759] __netif_receive_skb_list_core+0x12d/0x260 [ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0 [ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core] [ 843.991170] napi_complete_done+0x72/0x1a0 [ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core] [ 843.997501] __napi_poll+0x25/0x1b0 [ 844.000627] net_rx_action+0x256/0x330 [ 844.003705] __do_softirq+0xb3/0x29b [ 844.006718] irq_exit_rcu+0x9e/0xc0 [ 844.009672] common_interrupt+0x86/0xa0 [ 844.012537] </IRQ> [ 844.015285] <TASK> [ 844.017937] asm_common_interrupt+0x26/0x40 [ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20 [ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb ---truncated--- | ["https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4","https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4","https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6","https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97","https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441","https://git.kernel.org/stable/c/0b5b831122fc3789fff75be433ba3e4dd7b779d4","https://git.kernel.org/stable/c/172ba7d46c202e679f3ccb10264c67416aaeb1c4","https://git.kernel.org/stable/c/3f14b377d01d8357eba032b4cabc8c1149b458b6","https://git.kernel.org/stable/c/73f7da5fd124f2cda9161e2e46114915e6e82e97","https://git.kernel.org/stable/c/f5346df0591d10bc948761ca854b1fae6d2ef441"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26602 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. | ["https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265","https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a","https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3","https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee","https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23","https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71","https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea","https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6","https://git.kernel.org/stable/c/2441a64070b85c14eecc3728cc87e883f953f265","https://git.kernel.org/stable/c/24ec7504a08a67247fbe798d1de995208a8c128a","https://git.kernel.org/stable/c/3cd139875e9a7688b3fc715264032620812a5fa3","https://git.kernel.org/stable/c/50fb4e17df319bb33be6f14e2a856950c1577dee","https://git.kernel.org/stable/c/944d5fe50f3f03daacfea16300e656a1691c4a23","https://git.kernel.org/stable/c/b6a2a9cbb67545c825ec95f06adb7ff300a2ad71","https://git.kernel.org/stable/c/c5b2063c65d05e79fad8029324581d86cfba7eea","https://git.kernel.org/stable/c/db896bbe4a9c67cee377e5f6a743350d3ae4acf6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52463 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] ---[ end trace 0000000000000000 ]--- Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that's not RO if the firmware doesn't implement SetVariable at runtime. | ["https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737","https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe","https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826","https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8","https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548","https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b","https://git.kernel.org/stable/c/0049fe7e4a85849bdd778cdb72e51a791ff3d737","https://git.kernel.org/stable/c/0e8d2444168dd519fea501599d150e62718ed2fe","https://git.kernel.org/stable/c/2aa141f8bc580f8f9811dfe4e0e6009812b73826","https://git.kernel.org/stable/c/94c742324ed7e42c5bd6a9ed22e4ec6d764db4d8","https://git.kernel.org/stable/c/d4a714873db0866cc471521114eeac4a5072d548","https://git.kernel.org/stable/c/d4a9aa7db574a0da64307729cc031fb68597aa8b","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26900 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: md: fix kmemleak of rdev->serial If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 | ["https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366","https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b235bb4c4","https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea","https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995","https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9","https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9","https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123","https://git.kernel.org/stable/c/4c1021ce46fc2fb6115f7e79d353941e6dcad366","https://git.kernel.org/stable/c/6cf350658736681b9d6b0b6e58c5c76b235bb4c4","https://git.kernel.org/stable/c/6d32c832a88513f65c2c2c9c75954ee8b387adea","https://git.kernel.org/stable/c/9fd0198f7ef06ae0d6636fb0578560857dead995","https://git.kernel.org/stable/c/beaf11969fd5cbe6f09cefaa34df1ce8578e8dd9","https://git.kernel.org/stable/c/f3a1787dc48213f6caea5ba7d47e0222e7fa34a9","https://git.kernel.org/stable/c/fb5b347efd1bda989846ffc74679d181222fb123","https://lists.debian.org/debian-lts-announce/2024/06/msg00019.html","https://security.netapp.com/advisory/ntap-20240912-0011/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52595 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw(). | ["https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83","https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c","https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e","https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957","https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8","https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48","https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb","https://git.kernel.org/stable/c/04cfe4a5da57ab9358cdfadea22bcb37324aaf83","https://git.kernel.org/stable/c/4cc198580a7b93a36f5beb923f40f7ae27a3716c","https://git.kernel.org/stable/c/69e905beca193125820c201ab3db4fb0e245124e","https://git.kernel.org/stable/c/739b3ccd9486dff04af95f9a890846d088a84957","https://git.kernel.org/stable/c/a11d965a218f0cd95b13fe44d0bcd8a20ce134a8","https://git.kernel.org/stable/c/e1f113b57ddd18274d7c83618deca25cc880bc48","https://git.kernel.org/stable/c/fdb580ed05df8973aa5149cafa598c64bebcd0cb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3595 | Medium | fixed |
|
A vulnerability was found in Linux Kernel. It has been rated as problematic. Affected by this issue is the function sess_free_buffer of the file fs/cifs/sess.c of the component CIFS Handler. The manipulation leads to double free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211364. | ["https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b854b4ee66437e6e1622fda90529c814978cb4ca","https://vuldb.com/?id.211364","https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=b854b4ee66437e6e1622fda90529c814978cb4ca","https://vuldb.com/?id.211364"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3544 | Medium | fixed |
|
A vulnerability, which was classified as problematic, was found in Linux Kernel. Affected is the function damon_sysfs_add_target of the file mm/damon/sysfs.c of the component Netfilter. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211044. | ["https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git/commit/?id=1c8e2349f2d033f634d046063b704b2ca6c46972","https://vuldb.com/?id.211044","https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf-next.git/commit/?id=1c8e2349f2d033f634d046063b704b2ca6c46972","https://vuldb.com/?id.211044"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3212 | Medium | fixed |
|
A NULL pointer dereference issue was found in the gfs2 file system in the Linux kernel. It occurs on corrupt gfs2 file systems when the evict code tries to reference the journal descriptor structure after it has been freed and set to NULL. A privileged local user could use this flaw to cause a kernel panic. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2214348","https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0005/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://bugzilla.redhat.com/show_bug.cgi?id=2214348","https://github.com/torvalds/linux/commit/504a10d9e46bc37b23d0a1ae2f28973c8516e636","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://security.netapp.com/advisory/ntap-20230929-0005/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52617 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PCI: switchtec: Fix stdev_release() crash after surprise hot remove A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com | ["https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3","https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a","https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c","https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355","https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66","https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693","https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8","https://git.kernel.org/stable/c/0233b836312e39a3c763fb53512b3fa455b473b3","https://git.kernel.org/stable/c/1d83c85922647758c1f1e4806a4c5c3cf591a20a","https://git.kernel.org/stable/c/4a5d0528cf19dbf060313dffbe047bc11c90c24c","https://git.kernel.org/stable/c/d8c293549946ee5078ed0ab77793cec365559355","https://git.kernel.org/stable/c/df25461119d987b8c81d232cfe4411e91dcabe66","https://git.kernel.org/stable/c/e129c7fa7070fbce57feb0bfc5eaa65eef44b693","https://git.kernel.org/stable/c/ff1c7e2fb9e9c3f53715fbe04d3ac47b80be7eb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2021-3743 | High | fixed |
|
An out-of-bounds (OOB) memory read flaw was found in the Qualcomm IPC router protocol in the Linux kernel. A missing sanity check allows a local attacker to gain access to out-of-bounds memory, leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability. | ["https://bugzilla.redhat.com/show_bug.cgi?id=1997961","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117","https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117","https://lists.openwall.net/netdev/2021/08/17/124","https://security.netapp.com/advisory/ntap-20220407-0007/","https://www.openwall.com/lists/oss-security/2021/08/27/2","https://www.oracle.com/security-alerts/cpujul2022.html","https://bugzilla.redhat.com/show_bug.cgi?id=1997961","https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=7e78c597c3eb","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e78c597c3ebfd0cb329aa09a838734147e4f117","https://github.com/torvalds/linux/commit/7e78c597c3ebfd0cb329aa09a838734147e4f117","https://lists.openwall.net/netdev/2021/08/17/124","https://security.netapp.com/advisory/ntap-20220407-0007/","https://www.openwall.com/lists/oss-security/2021/08/27/2","https://www.oracle.com/security-alerts/cpujul2022.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-45863 | Medium | fixed |
|
An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.3","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bb2a01caa813d3a1845d378bbe4169ef280d394","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52598 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc register correctly If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl(). | ["https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1","https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25","https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713","https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8","https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3","https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a","https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829","https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4","https://git.kernel.org/stable/c/02c6bbfb08bad78dd014e24c7b893723c15ec7a1","https://git.kernel.org/stable/c/28a1f492cb527f64593457a0a0f0d809b3f36c25","https://git.kernel.org/stable/c/6ccf904aac0292e1f6b1a1be6c407c414f7cf713","https://git.kernel.org/stable/c/6d0822f2cc9b153bf2df49a84599195a2e0d21a8","https://git.kernel.org/stable/c/7a4d6481fbdd661f9e40e95febb95e3dee82bad3","https://git.kernel.org/stable/c/856caf2730ea18cb39e95833719c02a02447dc0a","https://git.kernel.org/stable/c/8b13601d19c541158a6e18b278c00ba69ae37829","https://git.kernel.org/stable/c/bdce67df7f12fb0409fbc604ce7c4254703f56d4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3141 | High | fixed |
|
A use-after-free flaw was found in r592_remove in drivers/memstick/host/r592.c in media access in the Linux Kernel. This flaw allows a local attacker to crash the system at device disconnect, possibly leading to a kernel information leak. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/","https://security.netapp.com/advisory/ntap-20230706-0004/","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.4","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63264422785021704c39b38f65a78ab9e4a186d7","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/CAPDyKFoV9aZObZ5GBm0U_-UVeVkBN_rAG-kH3BKoP4EXdYM4bw%40mail.gmail.com/t/","https://security.netapp.com/advisory/ntap-20230706-0004/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52628 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: exthdr: fix 4-byte stack OOB write If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption. This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does. The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added. Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961). | ["https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082","https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a","https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698","https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce","https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb","https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc","https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36","https://git.kernel.org/stable/c/1ad7b189cc1411048434e8595ffcbe7873b71082","https://git.kernel.org/stable/c/28a97c43c9e32f437ebb8d6126f9bb7f3ca9521a","https://git.kernel.org/stable/c/a7d86a77c33ba1c357a7504341172cc1507f0698","https://git.kernel.org/stable/c/c8f292322ff16b9a2272a67de396c09a50e09dce","https://git.kernel.org/stable/c/cf39c4f77a773a547ac2bcf30ecdd303bb0c80cb","https://git.kernel.org/stable/c/d9ebfc0f21377690837ebbd119e679243e0099cc","https://git.kernel.org/stable/c/fd94d9dadee58e09b49075240fe83423eb1dcd36"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26665 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tunnels: fix out of bounds access when building IPv6 PMTU error If the ICMPv6 error is built from a non-linear skb we get the following splat, BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240 Read of size 4 at addr ffff88811d402c80 by task netperf/820 CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543 ... kasan_report+0xd8/0x110 do_csum+0x220/0x240 csum_partial+0xc/0x20 skb_tunnel_check_pmtu+0xeb9/0x3280 vxlan_xmit_one+0x14c2/0x4080 vxlan_xmit+0xf61/0x5c00 dev_hard_start_xmit+0xfb/0x510 __dev_queue_xmit+0x7cd/0x32a0 br_dev_queue_push_xmit+0x39d/0x6a0 Use skb_checksum instead of csum_partial who cannot deal with non-linear SKBs. | ["https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1","https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab","https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06","https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a","https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732","https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d","https://git.kernel.org/stable/c/510c869ffa4068c5f19ff4df51d1e2f3a30aaac1","https://git.kernel.org/stable/c/7dc9feb8b1705cf00de20563b6bc4831f4c99dab","https://git.kernel.org/stable/c/d75abeec401f8c86b470e7028a13fcdc87e5dd06","https://git.kernel.org/stable/c/d964dd1bc1452594b4207d9229c157d9386e5d8a","https://git.kernel.org/stable/c/e37cde7a5716466ff2a76f7f27f0a29b05b9a732","https://git.kernel.org/stable/c/e77bf828f1ca1c47fcff58bdc26b60a9d3dfbe1d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52507 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn't potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones. | ["https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213","https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53","https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0","https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da","https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848","https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb","https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802","https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729","https://git.kernel.org/stable/c/25dd54b95abfdca423b65a4ee620a774777d8213","https://git.kernel.org/stable/c/2c231a247a1d1628e41fa1eefd1a5307c41c5f53","https://git.kernel.org/stable/c/354a6e707e29cb0c007176ee5b8db8be7bd2dee0","https://git.kernel.org/stable/c/6584eba7688dcf999542778b07f63828c21521da","https://git.kernel.org/stable/c/853dda54ba59ea70d5580a298b7ede4707826848","https://git.kernel.org/stable/c/95733ea130e35ef9ec5949a5908dde3feaba92cb","https://git.kernel.org/stable/c/a424807d860ba816aaafc3064b46b456361c0802","https://git.kernel.org/stable/c/a686f84101680b8442181a8846fbd3c934653729"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26673 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object. | ["https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98","https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8","https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d","https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4","https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f","https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e","https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483","https://git.kernel.org/stable/c/0f501dae16b7099e69ee9b0d5c70b8f40fd30e98","https://git.kernel.org/stable/c/38cc1605338d99205a263707f4dde76408d3e0e8","https://git.kernel.org/stable/c/65ee90efc928410c6f73b3d2e0afdd762652c09d","https://git.kernel.org/stable/c/8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4","https://git.kernel.org/stable/c/b775ced05489f4b77a35fe203e9aeb22f428e38f","https://git.kernel.org/stable/c/cfe3550ea5df292c9e2d608e8c4560032391847e","https://git.kernel.org/stable/c/f549f340c91f08b938d60266e792ff7748dae483","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26791 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: dev-replace: properly validate device names There's a syzbot report that device name buffers passed to device replace are not properly checked for string termination which could lead to a read out of bounds in getname_kernel(). Add a helper that validates both source and target device name buffers. For devid as the source initialize the buffer to empty string in case something tries to read it later. This was originally analyzed and fixed in a different way by Edward Adam Davis (see links). | ["https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84","https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d","https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb","https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4","https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9","https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1","https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311","https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8","https://git.kernel.org/stable/c/11d7a2e429c02d51e2dc90713823ea8b8d3d3a84","https://git.kernel.org/stable/c/2886fe308a83968dde252302884a1e63351cf16d","https://git.kernel.org/stable/c/343eecb4ff49a7b1cc1dfe86958a805cf2341cfb","https://git.kernel.org/stable/c/9845664b9ee47ce7ee7ea93caf47d39a9d4552c4","https://git.kernel.org/stable/c/ab2d68655d0f04650bef09fee948ff80597c5fb9","https://git.kernel.org/stable/c/b1690ced4d2d8b28868811fb81cd33eee5aefee1","https://git.kernel.org/stable/c/c6652e20d7d783d060fe5f987eac7b5cabe31311","https://git.kernel.org/stable/c/f590040ce2b712177306b03c2a63b16f7d48d3c8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39192 | Medium | fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The xt_u32 module did not validate the fields in the xt_u32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure. | ["https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39192","https://bugzilla.redhat.com/show_bug.cgi?id=2226784","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39192","https://bugzilla.redhat.com/show_bug.cgi?id=2226784","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18408/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1855 | Medium | fixed |
|
A use-after-free flaw was found in xgene_hwmon_remove in drivers/hwmon/xgene-hwmon.c in the Hardware Monitoring Linux Kernel Driver (xgene-hwmon). This flaw could allow a local attacker to crash the system due to a race problem. This vulnerability could even lead to a kernel information leak problem. | ["https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/","https://github.com/torvalds/linux/commit/cb090e64cf25602b9adaf32d5dfc9c8bec493cd1","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/all/20230318122758.2140868-1-linux%40roeck-us.net/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0160 | Medium | fixed |
|
A deadlock flaw was found in the Linux kernel’s BPF subsystem. This flaw allows a local user to potentially crash the system. | ["https://access.redhat.com/security/cve/CVE-2023-0160","https://bugzilla.redhat.com/show_bug.cgi?id=2159764","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56","https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/","https://access.redhat.com/security/cve/CVE-2023-0160","https://bugzilla.redhat.com/show_bug.cgi?id=2159764","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ed17aa92dc56","https://lore.kernel.org/all/CABcoxUayum5oOqFMMqAeWuS8+EzojquSOSyDA3J_2omY=2EeAg@mail.gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0775 | High | fixed |
|
A use-after-free flaw was found in the __ext4_remount in fs/ext4/super.c in ext4 in the Linux kernel. This flaw allows a local user to cause an information leak problem while freeing the old quota file names before a potential failure, leading to a use-after-free. | ["https://access.redhat.com/security/cve/CVE-2024-0775","https://bugzilla.redhat.com/show_bug.cgi?id=2259414","https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162","https://access.redhat.com/security/cve/CVE-2024-0775","https://bugzilla.redhat.com/show_bug.cgi?id=2259414","https://scm.linefinity.com/common/linux-stable/commit/4c0b4818b1f636bc96359f7817a2d8bab6370162"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-33981 | Low | fixed |
|
drivers/block/floppy.c in the Linux kernel before 5.17.6 is vulnerable to a denial of service, because of a concurrency use-after-free flaw after deallocating raw_cmd in the raw_cmd_ioctl function. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.6","https://exchange.xforce.ibmcloud.com/vulnerabilities/225362","https://github.com/torvalds/linux/commit/233087ca063686964a53c829d547c7571e3f67bf","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://seclists.org/oss-sec/2022/q2/66","https://www.debian.org/security/2022/dsa-5173","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.6","https://exchange.xforce.ibmcloud.com/vulnerabilities/225362","https://github.com/torvalds/linux/commit/233087ca063686964a53c829d547c7571e3f67bf","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://seclists.org/oss-sec/2022/q2/66","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3772 | Medium | N/A | A flaw was found in the Linux kernel’s IP framework for transforming packets (XFRM subsystem). This issue may allow a malicious user with CAP_NET_ADMIN privileges to directly dereference a NULL pointer in xfrm_update_ae_params(), leading to a possible kernel crash and denial of service. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/security/cve/CVE-2023-3772","https://bugzilla.redhat.com/show_bug.cgi?id=2218943","http://www.openwall.com/lists/oss-security/2023/08/10/1","http://www.openwall.com/lists/oss-security/2023/08/10/3","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:0575","https://access.redhat.com/security/cve/CVE-2023-3772","https://bugzilla.redhat.com/show_bug.cgi?id=2218943","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0459 | Medium | fixed |
|
Copy_from_user on 64-bit versions of the Linux kernel does not implement the __uaccess_begin_nospec allowing a user to bypass the "access_ok" check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information. We recommend upgrading beyond commit 74e19ef0ff8061ef55957c3abd71614ef0f42f47 | ["https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c","https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47","https://github.com/torvalds/linux/commit/4b842e4e25b12951fa10dedb4bc16bc47e3b850c","https://github.com/torvalds/linux/commit/74e19ef0ff8061ef55957c3abd71614ef0f42f47"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-46862 | Medium | N/A | An issue was discovered in the Linux kernel through 6.5.9. During a race with SQ thread exit, an io_uring/fdinfo.c io_uring_show_fdinfo NULL pointer dereference can occur. | ["https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4","https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html","https://bugzilla.kernel.org/show_bug.cgi?id=218032#c4","https://github.com/torvalds/linux/commit/7644b1a1c9a7ae8ab99175989bfc8676055edb46","https://lists.debian.org/debian-lts-announce/2024/01/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6176 | Medium | N/A | A null pointer dereference flaw was found in the Linux kernel API for the cryptographic algorithm scatterwalk functionality. This issue occurs when a user constructs a malicious packet with specific socket configuration, which could allow a local user to crash the system or escalate their privileges on the system. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6176","https://bugzilla.redhat.com/show_bug.cgi?id=2219359","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066","http://packetstormsecurity.com/files/177029/Kernel-Live-Patch-Security-Notice-LSN-0100-1.html","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-6176","https://bugzilla.redhat.com/show_bug.cgi?id=2219359","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfaa80c91f6f99b9342b6557f0f0e1143e434066"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52643 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: core: fix memleak in iio_device_register_sysfs When iio_device_register_sysfs_group() fails, we should free iio_dev_opaque->chan_attr_group.attrs to prevent potential memleak. | ["https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363","https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2","https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93","https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81","https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728","https://git.kernel.org/stable/c/1c6d19c8cbf6abcea2c8fca2db26abca2cbf0363","https://git.kernel.org/stable/c/359f220d0e753bba840eac19ffedcdc816b532f2","https://git.kernel.org/stable/c/3db312e06851996e7fb27cb5a8ccab4c0f9cdb93","https://git.kernel.org/stable/c/95a0d596bbd0552a78e13ced43f2be1038883c81","https://git.kernel.org/stable/c/b90126c86d83912688501826643ea698f0df1728"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26838 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix KASAN issue with tasklet KASAN testing revealed the following issue assocated with freeing an IRQ. [50006.466686] Call Trace: [50006.466691] <IRQ> [50006.489538] dump_stack+0x5c/0x80 [50006.493475] print_address_description.constprop.6+0x1a/0x150 [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.511644] kasan_report.cold.11+0x7f/0x118 [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.528232] irdma_process_ceq+0xb2/0x400 [irdma] [50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma] [50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma] [50006.545306] tasklet_action_common.isra.14+0x148/0x2c0 [50006.551096] __do_softirq+0x1d0/0xaf8 [50006.555396] irq_exit_rcu+0x219/0x260 [50006.559670] irq_exit+0xa/0x20 [50006.563320] smp_apic_timer_interrupt+0x1bf/0x690 [50006.568645] apic_timer_interrupt+0xf/0x20 [50006.573341] </IRQ> The issue is that a tasklet could be pending on another core racing the delete of the irq. Fix by insuring any scheduled tasklet is killed after deleting the irq. | ["https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc","https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824","https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa","https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb","https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848","https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc","https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824","https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa","https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb","https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26661 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()' In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL. | ["https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a","https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667","https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298","https://git.kernel.org/stable/c/39f24c08363af1cd945abad84e3c87fd3e3c845a","https://git.kernel.org/stable/c/3f3c237a706580326d3b7a1b97697e5031ca4667","https://git.kernel.org/stable/c/66951d98d9bf45ba25acf37fe0747253fafdf298"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26662 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()' 'panel_cntl' structure used to control the display panel could be null, dereferencing it could lead to a null pointer access. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250) | ["https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5","https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d","https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b","https://git.kernel.org/stable/c/0c863cab0e9173f8b6c7bc328bee3b8625f131b5","https://git.kernel.org/stable/c/2e150ccea13129eb048679114808eb9770443e4d","https://git.kernel.org/stable/c/e96fddb32931d007db12b1fce9b5e8e4c080401b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-42754 | Medium | fixed |
|
A NULL pointer dereference flaw was found in the Linux kernel ipv4 stack. The socket buffer (skb) was assumed to be associated with a device before calling __ip_options_compile, which is not always the case if the skb is re-routed by ipvs. This issue may allow a local user with CAP_NET_ADMIN privileges to crash the system. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42754","https://bugzilla.redhat.com/show_bug.cgi?id=2239845","https://seclists.org/oss-sec/2023/q4/14","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42754","https://bugzilla.redhat.com/show_bug.cgi?id=2239845","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/","https://seclists.org/oss-sec/2023/q4/14"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26717 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: i2c-hid-of: fix NULL-deref on failed power up A while back the I2C HID implementation was split in an ACPI and OF part, but the new OF driver never initialises the client pointer which is dereferenced on power-up failures. | ["https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f","https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776","https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783","https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c","https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3","https://git.kernel.org/stable/c/00aab7dcb2267f2aef59447602f34501efe1a07f","https://git.kernel.org/stable/c/4cad91344a62536a2949873bad6365fbb6232776","https://git.kernel.org/stable/c/62f5d219edbd174829aa18d4b3d97cd5fefbb783","https://git.kernel.org/stable/c/d7d7a0e3b6f5adc45f23667cbb919e99093a5b5c","https://git.kernel.org/stable/c/e28d6b63aeecbda450935fb58db0e682ea8212d3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26774 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid dividing by 0 in mb_update_avg_fragment_size() when block bitmap corrupt Determine if bb_fragments is 0 instead of determining bb_free to eliminate the risk of dividing by zero when the block bitmap is corrupted. | ["https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4","https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150","https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3","https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b","https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a","https://git.kernel.org/stable/c/687061cfaa2ac3095170e136dd9c29a4974f41d4","https://git.kernel.org/stable/c/8b40eb2e716b503f7a4e1090815a17b1341b2150","https://git.kernel.org/stable/c/8cf9cc602cfb40085967c0d140e32691c8b71cf3","https://git.kernel.org/stable/c/993bf0f4c393b3667830918f9247438a8f6fdb5b","https://git.kernel.org/stable/c/f32d2a745b02123258026e105a008f474f896d6a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26803 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths. | ["https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664","https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325","https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941","https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c","https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736","https://git.kernel.org/stable/c/16edf51f33f52dff70ed455bc40a6cc443c04664","https://git.kernel.org/stable/c/7985d73961bbb4e726c1be7b9cd26becc7be8325","https://git.kernel.org/stable/c/8f7a3894e58e6f5d5815533cfde60e3838947941","https://git.kernel.org/stable/c/f011c103e654d83dc85f057a7d1bd0960d02831c","https://git.kernel.org/stable/c/fe9f801355f0b47668419f30f1fac1cf4539e736"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3114 | Medium | fixed |
|
An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2153054","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=ed713e2bc093239ccd380c2ce8ae9e4162f5c037","https://bugzilla.redhat.com/show_bug.cgi?id=2153054","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.19-rc2\u0026id=ed713e2bc093239ccd380c2ce8ae9e4162f5c037"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52532 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging. | ["https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80","https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c","https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004","https://git.kernel.org/stable/c/a910e0f6304726da30a212feecec65cb97ff7a80","https://git.kernel.org/stable/c/b2b000069a4c307b09548dc2243f31f3ca0eac9c","https://git.kernel.org/stable/c/b67d7b1bfc46d05c1a58b172516454698e8d5004"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6679 | Medium | N/A | A null pointer dereference vulnerability was found in dpll_pin_parent_pin_set() in drivers/dpll/dpll_netlink.c in the Digital Phase Locked Loop (DPLL) subsystem in the Linux kernel. This issue could be exploited to trigger a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/security/cve/CVE-2023-6679","https://bugzilla.redhat.com/show_bug.cgi?id=2253986","https://lore.kernel.org/netdev/20231211083758.1082853-1-jiri@resnulli.us/","https://access.redhat.com/errata/RHSA-2024:0439","https://access.redhat.com/errata/RHSA-2024:0448","https://access.redhat.com/errata/RHSA-2024:0461","https://access.redhat.com/security/cve/CVE-2023-6679","https://bugzilla.redhat.com/show_bug.cgi?id=2253986","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/7LSPIOMIJYTLZB6QKPQVVAYSUETUWKPF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LBVHM4LGMFIHBN4UBESYRFMYX3WUICV5/","https://lore.kernel.org/netdev/20231211083758.1082853-1-jiri@resnulli.us/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52448 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump Syzkaller has reported a NULL pointer dereference when accessing rgd->rd_rgl in gfs2_rgrp_dump(). This can happen when creating rgd->rd_gl fails in read_rindex_entry(). Add a NULL pointer check in gfs2_rgrp_dump() to prevent that. | ["https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05","https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37","https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa","https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a","https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a","https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178","https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde","https://git.kernel.org/stable/c/067a7c48c2c70f05f9460d6f0e8423e234729f05","https://git.kernel.org/stable/c/5c28478af371a1c3fdb570ca67f110e1ae60fc37","https://git.kernel.org/stable/c/8877243beafa7c6bfc42022cbfdf9e39b25bd4fa","https://git.kernel.org/stable/c/c323efd620c741168c8e0cc6fc0be04ab57e331a","https://git.kernel.org/stable/c/d69d7804cf9e2ba171a27e5f98bc266f13d0414a","https://git.kernel.org/stable/c/ee0586d73cbaf0e7058bc640d62a9daf2dfa9178","https://git.kernel.org/stable/c/efc8ef87ab9185a23d5676f2f7d986022d91bcde","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52476 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a "none" branch if a kernel address if found to lie in the vsyscall region. | ["https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c","https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c","https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265","https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db","https://git.kernel.org/stable/c/3863989497652488a50f00e96de4331e5efabc6c","https://git.kernel.org/stable/c/403d201d1fd144cb249836dafb222f6375871c6c","https://git.kernel.org/stable/c/e53899771a02f798d436655efbd9d4b46c0f9265","https://git.kernel.org/stable/c/f71edacbd4f99c0e12fe4a4007ab4d687d0688db"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52580 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/core: Fix ETH_P_1588 flow dissector When a PTP ethernet raw frame with a size of more than 256 bytes followed by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation is wrong. For example: hdr->message_length takes the wrong value (0xffff) and it does not replicate real header length. In this case, 'nhoff' value was overridden and the PTP header was badly dissected. This leads to a kernel crash. net/core: flow_dissector net/core flow dissector nhoff = 0x0000000e net/core flow dissector hdr->message_length = 0x0000ffff net/core flow dissector nhoff = 0x0001000d (u16 overflow) ... skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Using the size of the ptp_header struct will allow the corrected calculation of the nhoff value. net/core flow dissector nhoff = 0x0000000e net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header) ... skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Kernel trace: [ 74.984279] ------------[ cut here ]------------ [ 74.989471] kernel BUG at include/linux/skbuff.h:2440! [ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1 [ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023 [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 [ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 [ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 [ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 [ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 [ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 [ 75.121980] PKRU: 55555554 [ 75.125035] Call Trace: [ 75.127792] <IRQ> [ 75.130063] ? eth_get_headlen+0xa4/0xc0 [ 75.134472] igc_process_skb_fields+0xcd/0x150 [ 75.139461] igc_poll+0xc80/0x17b0 [ 75.143272] __napi_poll+0x27/0x170 [ 75.147192] net_rx_action+0x234/0x280 [ 75.151409] __do_softirq+0xef/0x2f4 [ 75.155424] irq_exit_rcu+0xc7/0x110 [ 75.159432] common_interrupt+0xb8/0xd0 [ 75.163748] </IRQ> [ 75.166112] <TASK> [ 75.168473] asm_common_interrupt+0x22/0x40 [ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350 [ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 [ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202 [ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f [ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20 [ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001 [ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980 [ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000 [ 75.245635] ? ---truncated--- | ["https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40","https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48","https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3","https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9","https://git.kernel.org/stable/c/488ea2a3e2666022f79abfdd7d12e8305fc27a40","https://git.kernel.org/stable/c/48e105a2a1a10adc21c0ae717969f5e8e990ba48","https://git.kernel.org/stable/c/75ad80ed88a182ab2ad5513e448cf07b403af5c3","https://git.kernel.org/stable/c/f90a7b9586d72f907092078a9f394733ca502cc9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52435 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: prevent mss overflow in skb_segment() Once again syzbot is able to crash the kernel in skb_segment() [1] GSO_BY_FRAGS is a forbidden value, but unfortunately the following computation in skb_segment() can reach it quite easily : mss = mss * partial_segs; 65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to a bad final result. Make sure to limit segmentation so that the new mss value is smaller than GSO_BY_FRAGS. [1] general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0 R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046 FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109 ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120 skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53 __skb_gso_segment+0x339/0x710 net/core/gso.c:124 skb_gso_segment include/net/gso.h:83 [inline] validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626 __dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f8692032aa9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9 RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480 R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551 Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00 RSP: 0018:ffffc900043473d0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597 RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070 RBP: ffffc90004347578 R0 ---truncated--- | ["https://git.kernel.org/stable/c/0d3ffbbf8631d6db0552f46250015648991c856f","https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7","https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a","https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3","https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77","https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137","https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083","https://git.kernel.org/stable/c/23d05d563b7e7b0314e65c8e882bc27eac2da8e7","https://git.kernel.org/stable/c/6c53e8547687d9c767c139cd4b50af566f58c29a","https://git.kernel.org/stable/c/8f8f185643747fbb448de6aab0efa51c679909a3","https://git.kernel.org/stable/c/95b3904a261a9f810205da560e802cc326f50d77","https://git.kernel.org/stable/c/989b0ff35fe5fc9652ee5bafbe8483db6f27b137","https://git.kernel.org/stable/c/cd1022eaf87be8e6151435bd4df4c242c347e083","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52520 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"), so it seems that the bug was copied from that driver. Compile-tested only. | ["https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293","https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81","https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4","https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106","https://git.kernel.org/stable/c/124cf0ea4b82e1444ec8c7420af4e7db5558c293","https://git.kernel.org/stable/c/528ab3e605cabf2f9c9bd5944d3bfe15f6e94f81","https://git.kernel.org/stable/c/af21c9119a37cecb7ff27ce0c2f3cf721e9d0ec4","https://git.kernel.org/stable/c/c6e3023579de8d33256771ac0745239029e81106"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52523 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. However in commit 122e6c79efe1 ("sock_map: Update sock type checks for UDP") we have enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer dereference, address: 000000000000002f ... Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160 ? do_user_addr_fault+0x2d7/0x800 ? rcu_is_watching+0x11/0x50 ? exc_page_fault+0x70/0x1c0 ? asm_exc_page_fault+0x27/0x30 ? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0 ? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60 ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg program to prevent the crash. When attempted, user will receive an EACCES error from send/sendto/sendmsg() syscall. | ["https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5","https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2","https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728","https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089","https://git.kernel.org/stable/c/b80e31baa43614e086a9d29dc1151932b1bd7fc5","https://git.kernel.org/stable/c/b8f97e47b6fb84fcf2f5a22e725eefb6cf5070c2","https://git.kernel.org/stable/c/bc8b89b6963803a123f64aa9494155a037b3d728","https://git.kernel.org/stable/c/ded6e448028f0f91b6af35985afca01fa02a9089"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52559 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid memory allocation in iommu_suspend() The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. Allocating memory with the GFP_KERNEL flag may re-enable IRQs during the suspend callback, which can cause intermittent suspend/hibernation problems with the following kernel traces: Calling iommu_suspend+0x0/0x1d0 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 ... CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 ... Call Trace: <IRQ> tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1f/0x30 ... ------------[ cut here ]------------ Interrupts enabled after iommu_suspend+0x0/0x1d0 WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 ... Call Trace: <TASK> hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Given that only 4 words memory is needed, avoid the memory allocation in iommu_suspend(). | ["https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e","https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0","https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e","https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282","https://git.kernel.org/stable/c/29298c85a81abdc512e87537515ed4b1a9601d0e","https://git.kernel.org/stable/c/496c591f0b389eb782f36d9d4c2564b9a865eed0","https://git.kernel.org/stable/c/59df44bfb0ca4c3ee1f1c3c5d0ee8e314844799e","https://git.kernel.org/stable/c/c12ef025add77ca3a0902e8719d552b6d47b4282"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52582 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ------------[ cut here ]------------ kernel BUG at include/linux/netfs.h:44! ... CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 ... RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] ... Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50 | ["https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a","https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412","https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c","https://git.kernel.org/stable/c/d9f5537479d4ec97ea92ff24e81a517d5772581a","https://git.kernel.org/stable/c/df1c357f25d808e30b216188330e708e09e1a412","https://git.kernel.org/stable/c/df9950d37df113db59495fa09d060754366a2b7c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26595 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1]. Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 [...] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b | ["https://git.kernel.org/stable/c/75fa2d8b3c0175b519c99ace54ab8474cfd0077e","https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39","https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f","https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809","https://git.kernel.org/stable/c/817840d125a370626895df269c50c923b79b0a39","https://git.kernel.org/stable/c/d0a1efe417c97a1e9b914056ee6b86f1ef75fe1f","https://git.kernel.org/stable/c/efeb7dfea8ee10cdec11b6b6ba4e405edbe75809"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26700 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix MST Null Ptr for RV The change try to fix below error specific to RV platform: BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2 Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022 RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? plist_add+0xbe/0x100 ? exc_page_fault+0x7c/0x180 ? asm_exc_page_fault+0x26/0x30 ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026] compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] drm_atomic_check_only+0x5c5/0xa40 drm_mode_atomic_ioctl+0x76e/0xbc0 ? _copy_to_user+0x25/0x30 ? drm_ioctl+0x296/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 drm_ioctl_kernel+0xcd/0x170 drm_ioctl+0x26d/0x4b0 ? __pfx_drm_mode_atomic_ioctl+0x10/0x10 amdgpu_drm_ioctl+0x4e/0x90 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054] __x64_sys_ioctl+0x94/0xd0 do_syscall_64+0x60/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4dad17f76f Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c> RSP: 002b:00007ffd9ae859f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055e255a55900 RCX: 00007f4dad17f76f RDX: 00007ffd9ae85a90 RSI: 00000000c03864bc RDI: 000000000000000b RBP: 00007ffd9ae85a90 R08: 0000000000000003 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c03864bc R13: 000000000000000b R14: 000055e255a7fc60 R15: 000055e255a01eb0 </TASK> Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ccm cmac algif_hash algif_skcipher af_alg joydev mousedev bnep > typec libphy k10temp ipmi_msghandler roles i2c_scmi acpi_cpufreq mac_hid nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_mas> CR2: 0000000000000008 ---[ end trace 0000000000000000 ]--- RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper] Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224 RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280 RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850 R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000 R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224 FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000 ---truncated--- | ["https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238","https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f","https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5","https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57","https://git.kernel.org/stable/c/01d992088dce3945f70f49f34b0b911c5213c238","https://git.kernel.org/stable/c/5cd7185d2db76c42a9b7e69adad9591d9fca093f","https://git.kernel.org/stable/c/7407c61f43b66e90ad127d0cdd13cbc9d87141a5","https://git.kernel.org/stable/c/e6a7df96facdcf5b1f71eb3ec26f2f9f6ad61e57"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26844 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: block: Fix WARNING in _copy_from_iter Syzkaller reports a warning in _copy_from_iter because an iov_iter is supposedly used in the wrong direction. The reason is that syzcaller managed to generate a request with a transfer direction of SG_DXFER_TO_FROM_DEV. This instructs the kernel to copy user buffers into the kernel, read into the copied buffers and then copy the data back to user space. Thus the iovec is used in both directions. Detect this situation in the block layer and construct a new iterator with the correct direction for the copy-in. | ["https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956","https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6","https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b","https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b","https://git.kernel.org/stable/c/0f1bae071de9967602807472921829a54b2e5956","https://git.kernel.org/stable/c/13f3956eb5681a4045a8dfdef48df5dc4d9f58a6","https://git.kernel.org/stable/c/8fc80874103a5c20aebdc2401361aa01c817f75b","https://git.kernel.org/stable/c/cbaf9be337f7da25742acfce325119e3395b1f1b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-1016 | Medium | N/A | A flaw was found in the Linux kernel in net/netfilter/nf_tables_core.c:nft_do_chain, which can cause a use-after-free. This issue needs to handle 'return' with proper preconditions, as it can lead to a kernel information leak problem caused by a local, unprivileged attacker. | ["http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","https://access.redhat.com/security/cve/CVE-2022-1016","https://bugzilla.redhat.com/show_bug.cgi?id=2066614","https://seclists.org/oss-sec/2022/q1/205","http://blog.dbouman.nl/2022/04/02/How-The-Tables-Have-Turned-CVE-2022-1015-1016/","https://access.redhat.com/security/cve/CVE-2022-1016","https://bugzilla.redhat.com/show_bug.cgi?id=2066614","https://seclists.org/oss-sec/2022/q1/205"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4133 | Medium | fixed |
|
A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-4133","https://bugzilla.redhat.com/show_bug.cgi?id=2221702","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-4133","https://bugzilla.redhat.com/show_bug.cgi?id=2221702"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52508 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure pointer before dereference. | ["https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c","https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea","https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7","https://git.kernel.org/stable/c/8ae5b3a685dc59a8cf7ccfe0e850999ba9727a3c","https://git.kernel.org/stable/c/be90c9e29dd59b7d19a73297a1590ff3ec1d22ea","https://git.kernel.org/stable/c/dd46b3ac7322baf3772b33b29726e94f98289db7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26603 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ] | ["https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996","https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda","https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a","https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2","https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835","https://git.kernel.org/stable/c/627339cccdc9166792ecf96bc3c9f711a60ce996","https://git.kernel.org/stable/c/627e28cbb65564e55008315d9e02fbb90478beda","https://git.kernel.org/stable/c/8bd3eee7720c14b59a206bd05b98d7586bccf99a","https://git.kernel.org/stable/c/b2479ab426cef7ab79a13005650eff956223ced2","https://git.kernel.org/stable/c/d877550eaf2dc9090d782864c96939397a3c6835"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52576 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after the memblock allocator has already been torn down, potentially resulting in a use after free in memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid that bug. | ["https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b","https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204","https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b","https://git.kernel.org/stable/c/34cf99c250d5cd2530b93a57b0de31d3aaf8685b","https://git.kernel.org/stable/c/d2dfbc0e3b7a04c2d941421a958dc31c897fb204","https://git.kernel.org/stable/c/eef16bfdb212da60f5144689f2967fb25b051a2b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26881 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when 1588 is received on HIP08 devices The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel... | ["https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3","https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4","https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265","https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70","https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6","https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108","https://git.kernel.org/stable/c/0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3","https://git.kernel.org/stable/c/11b998360d96f6c76f04a95f54b49f24d3c858e4","https://git.kernel.org/stable/c/23ec1cec24293f9799c725941677d4e167997265","https://git.kernel.org/stable/c/b2bb19114c079dcfec1ea46e761f510e30505e70","https://git.kernel.org/stable/c/b3cf70472a600bcb2efe24906bc9bc6014d4c6f6","https://git.kernel.org/stable/c/f0b5225a7dfc1bf53c98215db8c2f0b4efd3f108"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48629 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: crypto: qcom-rng - ensure buffer for generate is completely filled The generate function in struct rng_alg expects that the destination buffer is completely filled if the function returns 0. qcom_rng_read() can run into a situation where the buffer is partially filled with randomness and the remaining part of the buffer is zeroed since qcom_rng_generate() doesn't check the return value. This issue can be reproduced by running the following from libkcapi: kcapi-rng -b 9000000 > OUTFILE The generated OUTFILE will have three huge sections that contain all zeros, and this is caused by the code where the test 'val & PRNG_STATUS_DATA_AVAIL' fails. Let's fix this issue by ensuring that qcom_rng_read() always returns with a full buffer if the function returns success. Let's also have qcom_rng_generate() return the correct value. Here's some statistics from the ent project (https://www.fourmilab.ch/random/) that shows information about the quality of the generated numbers: $ ent -c qcom-random-before Value Char Occurrences Fraction 0 606748 0.067416 1 33104 0.003678 2 33001 0.003667 ... 253 � 32883 0.003654 254 � 33035 0.003671 255 � 33239 0.003693 Total: 9000000 1.000000 Entropy = 7.811590 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 2 percent. Chi square distribution for 9000000 samples is 9329962.81, and randomly would exceed this value less than 0.01 percent of the times. Arithmetic mean value of data bytes is 119.3731 (127.5 = random). Monte Carlo value for Pi is 3.197293333 (error 1.77 percent). Serial correlation coefficient is 0.159130 (totally uncorrelated = 0.0). Without this patch, the results of the chi-square test is 0.01%, and the numbers are certainly not random according to ent's project page. The results improve with this patch: $ ent -c qcom-random-after Value Char Occurrences Fraction 0 35432 0.003937 1 35127 0.003903 2 35424 0.003936 ... 253 � 35201 0.003911 254 � 34835 0.003871 255 � 35368 0.003930 Total: 9000000 1.000000 Entropy = 7.999979 bits per byte. Optimum compression would reduce the size of this 9000000 byte file by 0 percent. Chi square distribution for 9000000 samples is 258.77, and randomly would exceed this value 42.24 percent of the times. Arithmetic mean value of data bytes is 127.5006 (127.5 = random). Monte Carlo value for Pi is 3.141277333 (error 0.01 percent). Serial correlation coefficient is 0.000468 (totally uncorrelated = 0.0). This change was tested on a Nexus 5 phone (msm8974 SoC). | ["https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b","https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d","https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d","https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b","https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d","https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd","https://git.kernel.org/stable/c/0f9b7b8df17525e464294c916acc8194ce38446b","https://git.kernel.org/stable/c/184f7bd08ce56f003530fc19f160d54e75bf5c9d","https://git.kernel.org/stable/c/485995cbc98a4f77cfd4f8ed4dd7ff8ab262964d","https://git.kernel.org/stable/c/a680b1832ced3b5fa7c93484248fd221ea0d614b","https://git.kernel.org/stable/c/a8e32bbb96c25b7ab29b1894dcd45e0b3b08fd9d","https://git.kernel.org/stable/c/ab9337c7cb6f875b6286440b1adfbeeef2b2b2bd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26744 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 | ["https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82","https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b","https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4","https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8","https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d","https://git.kernel.org/stable/c/e0055d6461b36bfc25a9d2ab974eef78d36a6738","https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0","https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f","https://git.kernel.org/stable/c/5a5c039dac1b1b7ba3e91c791f4421052bf79b82","https://git.kernel.org/stable/c/84f1dac960cfa210a3b7a7522e6c2320ae91932b","https://git.kernel.org/stable/c/989af2f29342a9a7c7515523d879b698ac8465f4","https://git.kernel.org/stable/c/aee4dcfe17219fe60f2821923adea98549060af8","https://git.kernel.org/stable/c/c99a827d3cff9f84e1cb997b7cc6386d107aa74d","https://git.kernel.org/stable/c/fdfa083549de5d50ebf7f6811f33757781e838c0","https://git.kernel.org/stable/c/fe2a73d57319feab4b3b175945671ce43492172f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26772 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted block bitmap. | ["https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a","https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43","https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d","https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513","https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff","https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916","https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586","https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7","https://git.kernel.org/stable/c/21dbe20589c7f48e9c5d336ce6402bcebfa6d76a","https://git.kernel.org/stable/c/5a6dcc4ad0f7f7fa8e8d127b5526e7c5f2d38a43","https://git.kernel.org/stable/c/6b92b1bc16d691c95b152c6dbf027ad64315668d","https://git.kernel.org/stable/c/832698373a25950942c04a512daa652c18a9b513","https://git.kernel.org/stable/c/8de8305a25bfda607fc13475ebe84b978c96d7ff","https://git.kernel.org/stable/c/d3bbe77a76bc52e9d4d0a120f1509be36e25c916","https://git.kernel.org/stable/c/d639102f4cbd4cb65d1225dba3b9265596aab586","https://git.kernel.org/stable/c/ffeb72a80a82aba59a6774b0611f792e0ed3b0b7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26777 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(), var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. | ["https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b","https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207","https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e","https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb","https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313","https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1","https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52","https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99","https://git.kernel.org/stable/c/1d11dd3ea5d039c7da089f309f39c4cd363b924b","https://git.kernel.org/stable/c/6db07619d173765bd8622d63809cbfe361f04207","https://git.kernel.org/stable/c/84246c35ca34207114055a87552a1c4289c8fd7e","https://git.kernel.org/stable/c/99f1abc34a6dde248d2219d64aa493c76bbdd9eb","https://git.kernel.org/stable/c/cd36da760bd1f78c63c7078407baf01dd724f313","https://git.kernel.org/stable/c/df6e2088c6f4cad539cf67cba2d6764461e798d1","https://git.kernel.org/stable/c/e421946be7d9bf545147bea8419ef8239cb7ca52","https://git.kernel.org/stable/c/f329523f6a65c3bbce913ad35473d83a319d5d99","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26778 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock equals zero The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. | ["https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288","https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4","https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1","https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24","https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff","https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1","https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01","https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13","https://git.kernel.org/stable/c/04e5eac8f3ab2ff52fa191c187a46d4fdbc1e288","https://git.kernel.org/stable/c/070398d32c5f3ab0e890374904ad94551c76aec4","https://git.kernel.org/stable/c/224453de8505aede1890f007be973925a3edf6a1","https://git.kernel.org/stable/c/512ee6d6041e007ef5bf200c6e388e172a2c5b24","https://git.kernel.org/stable/c/84dce0f6a4cc5b7bfd7242ef9290db8ac1dd77ff","https://git.kernel.org/stable/c/8c54acf33e5adaad6374bf3ec1e3aff0591cc8e1","https://git.kernel.org/stable/c/a9ca4e80d23474f90841251f4ac0d941fa337a01","https://git.kernel.org/stable/c/bc3c2e58d73b28b9a8789fca84778ee165a72d13","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45869 | Medium | fixed |
|
A race condition in the x86 KVM subsystem in the Linux kernel through 6.1-rc6 allows guest OS users to cause a denial of service (host OS crash or host OS memory corruption) when nested virtualisation and the TDP MMU are enabled. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47b0c2e4c220f2251fd8dcfbb44479819c715e15","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=47b0c2e4c220f2251fd8dcfbb44479819c715e15"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3521 | Low | fixed |
|
A vulnerability has been found in Linux Kernel and classified as problematic. This vulnerability affects the function kcm_tx_work of the file net/kcm/kcmsock.c of the component kcm. The manipulation leads to race condition. It is recommended to apply a patch to fix this issue. VDB-211018 is the identifier assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211018","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ec7eede369fe5b0d085ac51fdbb95184f87bfc6c","https://lists.debian.org/debian-lts-announce/2022/12/msg00031.html","https://lists.debian.org/debian-lts-announce/2022/12/msg00034.html","https://vuldb.com/?id.211018"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26769 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. | ["https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd","https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4","https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397","https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8","https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30","https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd","https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4","https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397","https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8","https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-28388 | Medium | N/A | usb_8dev_start_xmit in drivers/net/can/usb/usb_8dev.c in the Linux kernel through 5.17.1 has a double free. | ["https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173","https://github.com/torvalds/linux/commit/3d3925ff6433f98992685a9679613a2cc97f3ce2","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IHHC455LMSJNG4CSZ5CEAHYWY2DE5YW/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LAWC35TO642FOP3UCA3C6IF7NAUFOVZ6/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XFMPUI3WI4U2F7ONHRW36WDY4ZE7LGGT/","https://security.netapp.com/advisory/ntap-20220513-0001/","https://www.debian.org/security/2022/dsa-5127","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-33952 | Medium | N/A | A double-free vulnerability was found in handling vmw_buffer_object objects in the vmwgfx driver in the Linux kernel. This issue occurs due to the lack of validating the existence of an object prior to performing further free operations on the object, which may allow a local privileged user to escalate privileges and execute code in the context of the kernel. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33952","https://bugzilla.redhat.com/show_bug.cgi?id=2218212","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33952","https://bugzilla.redhat.com/show_bug.cgi?id=2218212","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20292"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3397 | Medium | N/A | A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information. | ["https://access.redhat.com/security/cve/CVE-2023-3397","https://bugzilla.redhat.com/show_bug.cgi?id=2217271","https://www.spinics.net/lists/kernel/msg4788636.html","https://access.redhat.com/security/cve/CVE-2023-3397","https://bugzilla.redhat.com/show_bug.cgi?id=2217271","https://www.spinics.net/lists/kernel/msg4788636.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-30456 | Medium | fixed |
|
An issue was discovered in arch/x86/kvm/vmx/nested.c in the Linux kernel before 6.2.8. nVMX on x86_64 lacks consistency checks for CR0 and CR4. | ["http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8","https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230511-0007/","http://packetstormsecurity.com/files/173757/Kernel-Live-Patch-Security-Notice-LSN-0096-1.html","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.8","https://github.com/torvalds/linux/commit/112e66017bff7f2837030f34c2bc19501e9212d5","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://security.netapp.com/advisory/ntap-20230511-0007/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26907 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- | ["https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c","https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350","https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d","https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd","https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21","https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa","https://git.kernel.org/stable/c/185fa07000e0a81d54cf8c05414cebff14469a5c","https://git.kernel.org/stable/c/4d5e86a56615cc387d21c629f9af8fb0e958d350","https://git.kernel.org/stable/c/60ba938a8bc8c90e724c75f98e932f9fb7ae1b9d","https://git.kernel.org/stable/c/9a624a5f95733bac4648ecadb320ca83aa9c08fd","https://git.kernel.org/stable/c/cad82f1671e41094acd3b9a60cd27d67a3c64a21","https://git.kernel.org/stable/c/d27c48dc309da72c3b46351a1205d89687272baa","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3624 | Low | N/A | A vulnerability was found in Linux Kernel and classified as problematic. Affected by this issue is the function rlb_arp_xmit of the file drivers/net/bonding/bond_alb.c of the component IPsec. The manipulation leads to memory leak. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211928. | ["https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=4f5d33f4f798b1c6d92b613f0087f639d9836971","https://vuldb.com/?id.211928","https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=4f5d33f4f798b1c6d92b613f0087f639d9836971","https://vuldb.com/?id.211928"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52529 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called. | ["https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e","https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74","https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f","https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d","https://git.kernel.org/stable/c/bb0707fde7492121917fd9ddb43829e96ec0bb9e","https://git.kernel.org/stable/c/e1cd4004cde7c9b694bbdd8def0e02288ee58c74","https://git.kernel.org/stable/c/f237b17611fa3501f43f12d1cb64323e10fdcb4f","https://git.kernel.org/stable/c/f566efa7de1e35e6523f4acbaf85068a540be07d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3268 | High | fixed |
|
An out of bounds (OOB) memory access flaw was found in the Linux kernel in relay_file_read_start_pos in kernel/relay.c in the relayfs. This flaw could allow a local attacker to crash the system or leak kernel internal information. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/","https://security.netapp.com/advisory/ntap-20230824-0006/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.3.2","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43ec16f1450f4936025a9bdf1a273affdb9732c1","https://lists.debian.org/debian-lts-announce/2023/07/msg00030.html","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lore.kernel.org/lkml/1682238502-1892-1-git-send-email-yangpc%40wangsu.com/T/","https://security.netapp.com/advisory/ntap-20230824-0006/","https://www.debian.org/security/2023/dsa-5448","https://www.debian.org/security/2023/dsa-5480"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1382 | Medium | fixed |
|
A data race flaw was found in the Linux kernel, between where con is allocated and con->sock is set. This issue leads to a NULL pointer dereference when accessing con->sock->sk in net/tipc/topsrv.c in the tipc protocol in the Linux kernel. | ["https://lore.kernel.org/netdev/bc7bd3183f1c275c820690fc65b708238fe9e38e.1668807842.git.lucien.xin%40gmail.com/T/#u","https://lore.kernel.org/netdev/bc7bd3183f1c275c820690fc65b708238fe9e38e.1668807842.git.lucien.xin%40gmail.com/T/#u"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26607 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: - tidss probes, but is deferred as sii902x is still missing. - sii902x starts probing and enters sii902x_init(). - sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM's perspective. - sii902x calls sii902x_audio_codec_init() and platform_device_register_data() - The registration of the audio platform device causes probing of the deferred devices. - tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. - sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe(). | ["https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9","https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c","https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1","https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076","https://git.kernel.org/stable/c/08ac6f132dd77e40f786d8af51140c96c6d739c9","https://git.kernel.org/stable/c/2a4c6af7934a7b4c304542c38fee35e09cc1770c","https://git.kernel.org/stable/c/56f96cf6eb11a1c2d594367c3becbfb06a855ec1","https://git.kernel.org/stable/c/e0f83c234ea7a3dec1f84e5d02caa1c51664a076"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0468 | Medium | fixed |
|
A use-after-free flaw was found in io_uring/poll.c in io_poll_check_events in the io_uring subcomponent in the Linux Kernel due to a race condition of poll_refs. This flaw may cause a NULL pointer dereference. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2164024","https://bugzilla.redhat.com/show_bug.cgi?id=2164024"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4010 | Medium | N/A | A flaw was found in the USB Host Controller Driver framework in the Linux kernel. The usb_giveback_urb function has a logic loophole in its implementation. Due to the inappropriate judgment condition of the goto statement, the function cannot return under the input of a specific malformed descriptor file, so it falls into an endless loop, resulting in a denial of service. | ["https://access.redhat.com/security/cve/CVE-2023-4010","https://bugzilla.redhat.com/show_bug.cgi?id=2227726","https://github.com/wanrenmi/a-usb-kernel-bug","https://access.redhat.com/security/cve/CVE-2023-4010","https://bugzilla.redhat.com/show_bug.cgi?id=2227726","https://github.com/wanrenmi/a-usb-kernel-bug"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-3606 | Medium | fixed |
|
A vulnerability was found in Linux Kernel. It has been classified as problematic. This affects the function find_prog_by_sec_insn of the file tools/lib/bpf/libbpf.c of the component BPF. The manipulation leads to null pointer dereference. It is recommended to apply a patch to fix this issue. The identifier VDB-211749 was assigned to this vulnerability. | ["https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2","https://vuldb.com/?id.211749","https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=d0d382f95a9270dcf803539d6781d6bd67e3f5b2","https://vuldb.com/?id.211749"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39189 | Medium | fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnl_osf_add_callback function did not validate the user mode controlled opt_num field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39189","https://bugzilla.redhat.com/show_bug.cgi?id=2226777","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39189","https://bugzilla.redhat.com/show_bug.cgi?id=2226777","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52573 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: rds: Fix possible NULL-pointer dereference In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists before dereferencing it as rdma_set_service_type() argument Found by Linux Verification Center (linuxtesting.org) with SVACE. | ["https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35","https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9","https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a","https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e","https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478","https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f","https://git.kernel.org/stable/c/069ac51c37a6f07a51f7134d8c34289075786a35","https://git.kernel.org/stable/c/51fa66024a5eabf270164f2dc82a48ffb35a12e9","https://git.kernel.org/stable/c/812da2a08dc5cc75fb71e29083ea20904510ac7a","https://git.kernel.org/stable/c/ea82139e6e3561100d38d14401d57c0ea93fc07e","https://git.kernel.org/stable/c/f1d95df0f31048f1c59092648997686e3f7d9478","https://git.kernel.org/stable/c/f515112e833791001aaa8ab886af3ca78503617f"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26776 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected Return IRQ_NONE from the interrupt handler when no interrupt was detected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc | ["https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d","https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4","https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9","https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd","https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5","https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8","https://git.kernel.org/stable/c/0399d7eba41d9b28f5bdd7757ec21a5b7046858d","https://git.kernel.org/stable/c/d637b5118274701e8448f35953877daf04df18b4","https://git.kernel.org/stable/c/de8b6e1c231a95abf95ad097b993d34b31458ec9","https://git.kernel.org/stable/c/e4168ac25b4bd378bd7dda322d589482a136c1fd","https://git.kernel.org/stable/c/e94da8aca2e78ef9ecca02eb211869eacd5504e5","https://git.kernel.org/stable/c/f19361d570c67e7e014896fa2dacd7d721bf0aa8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48628 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ceph: drop messages from MDS when unmounting When unmounting all the dirty buffers will be flushed and after the last osd request is finished the last reference of the i_count will be released. Then it will flush the dirty cap/snap to MDSs, and the unmounting won't wait the possible acks, which will ihold the inodes when updating the metadata locally but makes no sense any more, of this. This will make the evict_inodes() to skip these inodes. If encrypt is enabled the kernel generate a warning when removing the encrypt keys when the skipped inodes still hold the keyring: WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1 Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000 R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Later the kernel will crash when iput() the inodes and dereferencing the "sb->s_master_keys", which has been released by the generic_shutdown_super(). | ["https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571","https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5","https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd","https://git.kernel.org/stable/c/47f82395f04a976d4fa97de7f2acffa1c1096571","https://git.kernel.org/stable/c/89744b64914426cbabceb3d8a149176b5dafdfb5","https://git.kernel.org/stable/c/e3dfcab2080dc1f9a4b09cc1327361bc2845bfcd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-0615 | Medium | fixed |
|
A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2166287","https://bugzilla.redhat.com/show_bug.cgi?id=2166287"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-46343 | Medium | fixed |
|
In the Linux kernel before 6.5.9, there is a NULL pointer dereference in send_acknowledge in net/nfc/nci/spi.c. | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41","https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41","https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.5.9","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7937609cd387246aed994e81aa4fa951358fba41","https://github.com/torvalds/linux/commit/7937609cd387246aed994e81aa4fa951358fba41","https://lore.kernel.org/netdev/20231013184129.18738-1-krzysztof.kozlowski%40linaro.org/T/#r38bdbaf8ae15305b77f6c5bc8e15d38f405623c7"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26587 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: netdevsim: don't try to destroy PHC on VFs PHC gets initialized in nsim_init_netdevsim(), which is only called if (nsim_dev_port_is_pf()). Create a counterpart of nsim_init_netdevsim() and move the mock_phc_destroy() there. This fixes a crash trying to destroy netdevsim with VFs instantiated, as caught by running the devlink.sh test: BUG: kernel NULL pointer dereference, address: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Call Trace: <TASK> nsim_destroy+0x4a/0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] device_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 device_del+0x159/0x490 device_unregister+0x12/0x30 del_device_store+0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 | ["https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca","https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588","https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda","https://git.kernel.org/stable/c/08aca65997fb6f233066883b1f1e653bcb1f26ca","https://git.kernel.org/stable/c/c5068e442eed063d2f1658e6b6d3c1c6fcf1e588","https://git.kernel.org/stable/c/ea937f77208323d35ffe2f8d8fc81b00118bfcda"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-49441 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tty: fix deadlock caused by calling printk() under tty_port->lock pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below: CPU0 CPU1 CPU2 ---- ---- ---- lock(console_owner); lock(&port_lock_key); lock(&port->lock); lock(&port_lock_key); lock(&port->lock); lock(console_owner); As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printk_deferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printk_deferred() is too complicated and inelegant. Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided. Syzbot reported the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.4.143-00237-g08ccc19a-dirty #10 Not tainted ------------------------------------------------------ syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023 but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&port->lock){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 tty_port_tty_get drivers/tty/tty_port.c:288 [inline] <-- lock(&port->lock); tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47 serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767 serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] <-- lock(&port_lock_key); serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870 serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...] -> #1 (&port_lock_key){-.-.}-{2:2}: __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198 <-- lock(&port_lock_key); call_console_drivers kernel/printk/printk.c:1819 [inline] console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(console_owner); vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 register_console+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681 console_init+0x49d/0x6d3 kernel/printk/printk.c:2915 start_kernel+0x5e9/0x879 init/main.c:713 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241 -> #0 (console_owner){....}-{0:0}: [...] lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734 console_trylock_spinning kernel/printk/printk.c:1773 ---truncated--- | ["https://git.kernel.org/stable/c/04ee31678c128a6cc7bb057ea189a8624ba5a314","https://git.kernel.org/stable/c/0bcf44903ef4df742dcada86ccaedd25374ffb50","https://git.kernel.org/stable/c/18ca0d55e8639b911df8aae1b47598b13f9acded","https://git.kernel.org/stable/c/3219ac364ac3d8d30771612a6010f1e0b7fa0a28","https://git.kernel.org/stable/c/4af21b12a60ed2d3642284f4f85b42d7dc6ac246","https://git.kernel.org/stable/c/4c253caf9264d2aa47ee806a87986dd8eb91a5d9","https://git.kernel.org/stable/c/6b9dbedbe3499fef862c4dff5217cf91f34e43b3","https://git.kernel.org/stable/c/9834b13e8b962caa28fbcf1f422dd82413da4ede","https://git.kernel.org/stable/c/b3c974501d0c32258ae0e04e5cc3fb92383b40f6"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26691 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data. | ["https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc","https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc","https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228","https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc","https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc","https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26775 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: aoe: avoid potential deadlock at set_capacity Move set_capacity() outside of the section procected by (&d->lock). To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- [1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); <Interrupt> [4] lock(&d->lock); *** DEADLOCK *** Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity(). [2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc() is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call. In this situation an attempt to acquire [4]lock(&d->lock) from aoecmd_cfg_rsp() will lead to deadlock. So the simplest solution is breaking lock dependency [2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity() outside. | ["https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77","https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26","https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c","https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86","https://git.kernel.org/stable/c/19a77b27163820f793b4d022979ffdca8f659b77","https://git.kernel.org/stable/c/2d623c94fbba3554f4446ba6f3c764994e8b0d26","https://git.kernel.org/stable/c/673629018ba04906899dcb631beec34d871f709c","https://git.kernel.org/stable/c/e169bd4fb2b36c4b2bee63c35c740c85daeb2e86"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26891 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected For those endpoint devices connect to system via hotplug capable ports, users could request a hot reset to the device by flapping device's link through setting the slot's link control register, as pciehp_ist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU device-TLB invalidation (Intel VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence target device to be sent and deadly loop to retry that request after ITE fault triggered in interrupt context. That would cause following continuous hard lockup warning and system hang [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 0000000000000005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 0000000000000000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f384005e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 0000000000000004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 0000000000770ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] intel_iommu_release_device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 [ 4223.822630] device_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176/0x180 [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted: G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] <NMI> [ 4223.822635] dump_stack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? ret_from_fork+0x11/0x30 [ 4223.822635] nmi_panic.cold.14+0xc/0xc [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 [ 4223.822636] __perf_event_overflow+0x4f/0xf0 [ 4223.822636] handle_pmi_common ---truncated--- | ["https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05","https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062","https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf","https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b","https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868","https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554","https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85","https://git.kernel.org/stable/c/025bc6b41e020aeb1e71f84ae3ffce945026de05","https://git.kernel.org/stable/c/2b74b2a92e524d7c8dec8e02e95ecf18b667c062","https://git.kernel.org/stable/c/34a7b30f56d30114bf4d436e4dc793afe326fbcf","https://git.kernel.org/stable/c/4fc82cd907ac075648789cc3a00877778aa1838b","https://git.kernel.org/stable/c/c04f2780919f20e2cc4846764221f5e802555868","https://git.kernel.org/stable/c/d70f1c85113cd8c2aa8373f491ca5d1b22ec0554","https://git.kernel.org/stable/c/f873b85ec762c5a6abe94a7ddb31df5d3ba07d85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1076 | Medium | N/A | A flaw was found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function. While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability. This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters. | ["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cff","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52635 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled. Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff8 ---truncated--- | ["https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675","https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9","https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9","https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475","https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22","https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6","https://git.kernel.org/stable/c/099f6a9edbe30b142c1d97fe9a4748601d995675","https://git.kernel.org/stable/c/0aedb319ef3ed39e9e5a7b7726c8264ca627bbd9","https://git.kernel.org/stable/c/31569995fc65007b73a3fff605ec2b3401b435e9","https://git.kernel.org/stable/c/3399cc7013e761fee9d6eec795e9b31ab0cbe475","https://git.kernel.org/stable/c/ae815e2fdc284ab31651d52460698bd89c0fce22","https://git.kernel.org/stable/c/aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48619 | Medium | fixed |
|
An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.10","https://github.com/torvalds/linux/commit/409353cbe9fe48f6bc196114c442b1cff05a39bc","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.17.10","https://github.com/torvalds/linux/commit/409353cbe9fe48f6bc196114c442b1cff05a39bc"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52590 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ocfs2: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. | ["https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc","https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9","https://git.kernel.org/stable/c/9d618d19b29c2943527e3a43da0a35aea91062fc","https://git.kernel.org/stable/c/de940cede3c41624e2de27f805b490999f419df9"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26808 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER event is reported, otherwise a stale reference to netdevice remains in the hook list. | ["https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913","https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee","https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58","https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f","https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3","https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4","https://git.kernel.org/stable/c/01acb2e8666a6529697141a6017edbf206921913","https://git.kernel.org/stable/c/36a0a80f32209238469deb481967d777a3d539ee","https://git.kernel.org/stable/c/70f17b48c86622217a58d5099d29242fc9adac58","https://git.kernel.org/stable/c/9489e214ea8f2a90345516016aa51f2db3a8cc2f","https://git.kernel.org/stable/c/af149a46890e8285d1618bd68b8d159bdb87fdb3","https://git.kernel.org/stable/c/e5888acbf1a3d8d021990ce6c6061fd5b2bb21b4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4569 | Medium | fixed |
|
A memory leak flaw was found in nft_set_catchall_flush in net/netfilter/nf_tables_api.c in the Linux Kernel. This issue may allow a local attacker to cause double-deactivations of catchall elements, which can result in a memory leak. | ["https://access.redhat.com/security/cve/CVE-2023-4569","https://bugzilla.redhat.com/show_bug.cgi?id=2235470","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/","https://www.debian.org/security/2023/dsa-5492","https://access.redhat.com/security/cve/CVE-2023-4569","https://bugzilla.redhat.com/show_bug.cgi?id=2235470","https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230812110526.49808-1-fw@strlen.de/","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52627 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7091r: Allow users to configure device events AD7091R-5 devices are supported by the ad7091r-5 driver together with the ad7091r-base driver. Those drivers declared iio events for notifying user space when ADC readings fall bellow the thresholds of low limit registers or above the values set in high limit registers. However, to configure iio events and their thresholds, a set of callback functions must be implemented and those were not present until now. The consequence of trying to configure ad7091r-5 events without the proper callback functions was a null pointer dereference in the kernel because the pointers to the callback functions were not set. Implement event configuration callbacks allowing users to read/write event thresholds and enable/disable event generation. Since the event spec structs are generic to AD7091R devices, also move those from the ad7091r-5 driver the base driver so they can be reused when support for ad7091r-2/-4/-8 be added. | ["https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f","https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4","https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5","https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091","https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6","https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2","https://git.kernel.org/stable/c/020e71c7ffc25dfe29ed9be6c2d39af7bd7f661f","https://git.kernel.org/stable/c/137568aa540a9f587c48ff7d4c51cdba08cfe9a4","https://git.kernel.org/stable/c/1eba6f7ffa295a0eec098c107043074be7cc4ec5","https://git.kernel.org/stable/c/49f322ce1f265935f15e5512da69a399f27a5091","https://git.kernel.org/stable/c/55aca2ce91a63740278502066beaddbd841af9c6","https://git.kernel.org/stable/c/89c4e63324e208a23098f7fb15c00487cecbfed2","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-23850 | Medium | N/A | In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation. | ["https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://lore.kernel.org/all/6a80cb4b32af89787dadee728310e5e2ca85343f.1705741883.git.wqu%40suse.com/","https://lore.kernel.org/lkml/CALGdzuo6awWdau3X=8XK547x2vX_-VoFmH1aPsqosRTQ5WzJVA%40mail.gmail.com/","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/EZOU3745CWCDZ7EMKMXB2OEEIB5Q3IWM/","https://lore.kernel.org/all/6a80cb4b32af89787dadee728310e5e2ca85343f.1705741883.git.wqu%40suse.com/","https://lore.kernel.org/lkml/CALGdzuo6awWdau3X=8XK547x2vX_-VoFmH1aPsqosRTQ5WzJVA%40mail.gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26615 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net/smc: fix illegal rmb_desc access in SMC-D connection dump A crash was found when dumping SMC-D connections. It can be reproduced by following steps: - run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL> - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76 It is possible that the connection is in process of being established when we dump it. Assumed that the connection has been registered in a link group by smc_conn_create() but the rmb_desc has not yet been initialized by smc_buf_create(), thus causing the illegal access to conn->rmb_desc. So fix it by checking before dump. | ["https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be","https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22","https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d","https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a","https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a","https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6","https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9","https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c","https://git.kernel.org/stable/c/1fea9969b81c67d0cb1611d1b8b7d19049d937be","https://git.kernel.org/stable/c/27aea64838914c6122db5b8bd4bed865c9736f22","https://git.kernel.org/stable/c/5fed92ca32eafbfae8b6bee8ca34cca71c6a8b6d","https://git.kernel.org/stable/c/68b888d51ac82f2b96bf5e077a31d76afcdef25a","https://git.kernel.org/stable/c/6994dba06321e3c48fdad0ba796a063d9d82183a","https://git.kernel.org/stable/c/8f3f9186e5bb96a9c9654c41653210e3ea7e48a6","https://git.kernel.org/stable/c/a164c2922675d7051805cdaf2b07daffe44f20d9","https://git.kernel.org/stable/c/dbc153fd3c142909e564bb256da087e13fbf239c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26879 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: clk: meson: Add missing clocks to axg_clk_regmaps Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70 [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000 [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000 [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000 [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100 [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24 [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710 [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000 [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000 [ 57.519615] Call trace: [ 57.522030] regmap_read+0x1c/0x88 [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] clk_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.596031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] el0t_64_sync+0x190/0x198 [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] ---[ end trace 0000000000000000 ]--- [jbrunet: add missing Fixes tag] | ["https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7","https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202","https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8","https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84","https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10","https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418","https://git.kernel.org/stable/c/0cbefc7b5bdad86b18a263d837450cdc9a56f8d7","https://git.kernel.org/stable/c/7ae1b0dc12ec407f12f80b49d22c6ad2308e2202","https://git.kernel.org/stable/c/9f3e5df38b4528213449e55b80f0316864f2a1c8","https://git.kernel.org/stable/c/a03ed00787b0ce7a83eebabd0fa95ecc4a5cac84","https://git.kernel.org/stable/c/a860aaebacbc908fa06e2642402058f40bfffe10","https://git.kernel.org/stable/c/ba535bce57e71463a86f8b33a0ea88c26e3a6418"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39198 | Medium | fixed |
|
A race condition was found in the QXL driver in the Linux kernel. The qxl_mode_dumb_create() function dereferences the qobj returned by the qxl_gem_object_create_with_handle(), but the handle is the only one holding a reference to it. This flaw allows an attacker to guess the returned handle value and trigger a use-after-free issue, potentially leading to a denial of service or privilege escalation. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39198","https://bugzilla.redhat.com/show_bug.cgi?id=2218332","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39198","https://bugzilla.redhat.com/show_bug.cgi?id=2218332","https://lists.debian.org/debian-lts-announce/2024/06/msg00016.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4155 | Medium | N/A | A flaw was found in KVM AMD Secure Encrypted Virtualization (SEV) in the Linux kernel. A KVM guest using SEV-ES or SEV-SNP with multiple vCPUs can trigger a double fetch race condition vulnerability and invoke the `VMGEXIT` handler recursively. If an attacker manages to call the handler multiple times, they can trigger a stack overflow and cause a denial of service or potentially guest-to-host escape in kernel configurations without stack guard pages (`CONFIG_VMAP_STACK`). | ["https://access.redhat.com/security/cve/CVE-2023-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2213802","https://access.redhat.com/security/cve/CVE-2023-4155","https://bugzilla.redhat.com/show_bug.cgi?id=2213802"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-0854 | Medium | N/A | A memory leak flaw was found in the Linux kernel’s DMA subsystem, in the way a user calls DMA_FROM_DEVICE. This flaw allows a local user to read random memory from the kernel space. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/dma/swiotlb.c?h=v5.17-rc8\u0026id=aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/kernel/dma/swiotlb.c?h=v5.17-rc8\u0026id=aa6f8dcbab473f3a3c7454b74caa46d36cdc5d13","https://lists.debian.org/debian-lts-announce/2022/07/msg00000.html","https://www.debian.org/security/2022/dsa-5161","https://www.debian.org/security/2022/dsa-5173"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1611 | Medium | fixed |
|
A use-after-free flaw was found in btrfs_search_slot in fs/btrfs/ctree.c in btrfs in the Linux Kernel.This flaw allows an attacker to crash the system and possibly cause a kernel information lea | ["https://bugzilla.redhat.com/show_bug.cgi?id=2181342","https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/","https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/","https://bugzilla.redhat.com/show_bug.cgi?id=2181342","https://github.com/torvalds/linux/commit/2f1a6be12ab6c8470d5776e68644726c94257c54","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5QCM6XO4HSPLGR3DFYWFRIA3GCBIHZR4/","https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZWECAZ7V7EPSXMINO6Q6KWNKDY2CO6ZW/","https://lore.kernel.org/linux-btrfs/35b9a70650ea947387cf352914a8774b4f7e8a6f.1679481128.git.fdmanana%40suse.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26869 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to truncate meta inode pages forcely Below race case can cause data corruption: Thread A GC thread - gc_data_segment - ra_data_block - locked meta_inode page - f2fs_inplace_write_data - invalidate_mapping_pages : fail to invalidate meta_inode page due to lock failure or dirty|writeback status - f2fs_submit_page_bio : write last dirty data to old blkaddr - move_data_block - load old data from meta_inode page - f2fs_submit_page_write : write old data to new blkaddr Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped. | ["https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253","https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189","https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65","https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694","https://git.kernel.org/stable/c/04226d8e3c4028dc451e9d8777356ec0f7919253","https://git.kernel.org/stable/c/77bfdb89cc222fc7bfe198eda77bdc427d5ac189","https://git.kernel.org/stable/c/9f0c4a46be1fe9b97dbe66d49204c1371e3ece65","https://git.kernel.org/stable/c/c92f2927df860a60ba815d3ee610a944b92a8694"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26631 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work idev->mc_ifc_count can be written over without proper locking. Originally found by syzbot [1], fix this issue by encapsulating calls to mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with mutex_lock() and mutex_unlock() accordingly as these functions should only be called with mc_lock per their declarations. [1] BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work write to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ... write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ... | ["https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155","https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663","https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855","https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900","https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c","https://git.kernel.org/stable/c/2e7ef287f07c74985f1bf2858bedc62bd9ebf155","https://git.kernel.org/stable/c/380540bb06bb1d1b12bdc947d1b8f56cda6b5663","https://git.kernel.org/stable/c/3bb5849675ae1d592929798a2b37ea450879c855","https://git.kernel.org/stable/c/3cc283fd16fba72e2cefe3a6f48d7a36b0438900","https://git.kernel.org/stable/c/62b3387beef11738eb6ce667601a28fa089fa02c"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-45887 | Medium | N/A | An issue was discovered in the Linux kernel through 6.0.9. drivers/media/usb/ttusb-dec/ttusb_dec.c has a memory leak because of the lack of a dvb_frontend_detach call. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=517a281338322ff8293f988771c98aaa7205e457","https://lore.kernel.org/linux-media/20221115131822.6640-1-imv4bel%40gmail.com/","https://lore.kernel.org/linux-media/20221115131822.6640-5-imv4bel%40gmail.com/","https://security.netapp.com/advisory/ntap-20230113-0006/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39193 | Medium | fixed |
|
A flaw was found in the Netfilter subsystem in the Linux kernel. The sctp_mt_check did not validate the flag_count field. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39193","https://bugzilla.redhat.com/show_bug.cgi?id=2226787","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39193","https://bugzilla.redhat.com/show_bug.cgi?id=2226787","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18866/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26894 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffff9972f3b3>] acpi_processor_power_init+0xf3/0x1c0 [<ffffffff9972d263>] __acpi_processor_start+0xd3/0xf0 [<ffffffff9972d2bc>] acpi_processor_start+0x2c/0x50 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff9aee4acb>] acpi_processor_driver_init+0x3b/0xc0 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 [<ffffffff9ae7c4b0>] kernel_init_freeable+0x320/0x470 [<ffffffff99b231f6>] kernel_init+0x16/0x1b0 [<ffffffff99042e6d>] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it. | ["https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2","https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc","https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e","https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5","https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9","https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa","https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51","https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d","https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8","https://git.kernel.org/stable/c/1cbaf4c793b0808532f4e7b40bc4be7cec2c78f2","https://git.kernel.org/stable/c/3d48e5be107429ff5d824e7f2a00d1b610d36fbc","https://git.kernel.org/stable/c/8d14a4d0afb49a5b8535d414c782bb334860e73e","https://git.kernel.org/stable/c/c2a30c81bf3cb9033fa9f5305baf7c377075e2e5","https://git.kernel.org/stable/c/cd5c2d0b09d5b6d3f0a7bbabe6761a4997e9dee9","https://git.kernel.org/stable/c/d351bcadab6caa6d8ce7159ff4b77e2da35c09fa","https://git.kernel.org/stable/c/e18afcb7b2a12b635ac10081f943fcf84ddacc51","https://git.kernel.org/stable/c/ea96bf3f80625cddba1391a87613356b1b45716d","https://git.kernel.org/stable/c/fad9bcd4d754cc689c19dc04d2c44b82c1a5d6c8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-42755 | Medium | fixed |
|
A flaw was found in the IPv4 Resource Reservation Protocol (RSVP) classifier in the Linux kernel. The xprt pointer may go beyond the linear part of the skb, leading to an out-of-bounds read in the `rsvp_classify` function. This issue may allow a local user to crash the system and cause a denial of service. | ["https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42755","https://bugzilla.redhat.com/show_bug.cgi?id=2239847","https://seclists.org/oss-sec/2023/q3/229","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-42755","https://bugzilla.redhat.com/show_bug.cgi?id=2239847","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://seclists.org/oss-sec/2023/q3/229"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1513 | Low | fixed |
|
A flaw was found in KVM. When calling the KVM_GET_DEBUGREGS ioctl, on 32-bit systems, there might be some uninitialized portions of the kvm_debugregs structure that could be copied to userspace, causing an information leak. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2179892","https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/","https://bugzilla.redhat.com/show_bug.cgi?id=2179892","https://github.com/torvalds/linux/commit/2c10b61421a28e95a46ab489fd56c0f442ff6952","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://lore.kernel.org/kvm/20230214103304.3689213-1-gregkh%40linuxfoundation.org/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26810 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Lock external INTx masking ops Mask operations through config space changes to DisINTx may race INTx configuration changes via ioctl. Create wrappers that add locking for paths outside of the core interrupt code. In particular, irq_type is updated holding igate, therefore testing is_intx() requires holding igate. For example clearing DisINTx from config space can otherwise race changes of the interrupt configuration. This aligns interfaces which may trigger the INTx eventfd into two camps, one side serialized by igate and the other only enabled while INTx is configured. A subsequent patch introduces synchronization for the latter flows. | ["https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf","https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651","https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42","https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3","https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5","https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40","https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7","https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6","https://git.kernel.org/stable/c/03505e3344b0576fd619416793a31eae9c5b73bf","https://git.kernel.org/stable/c/04a4a017b9ffd7b0f427b8c376688d14cb614651","https://git.kernel.org/stable/c/1e71b6449d55179170efc8dee8664510bb813b42","https://git.kernel.org/stable/c/3dd9be6cb55e0f47544e7cdda486413f7134e3b3","https://git.kernel.org/stable/c/3fe0ac10bd117df847c93408a9d428a453cd60e5","https://git.kernel.org/stable/c/6fe478d855b20ac1eb5da724afe16af5a2aaaa40","https://git.kernel.org/stable/c/810cd4bb53456d0503cc4e7934e063835152c1b7","https://git.kernel.org/stable/c/ec73e079729258a05452356cf6d098bf1504d5a6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26855 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before proceeding with the nested attribute iteration. | ["https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c","https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f","https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3","https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309","https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19","https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596","https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb","https://git.kernel.org/stable/c/06e456a05d669ca30b224b8ed962421770c1496c","https://git.kernel.org/stable/c/0e296067ae0d74a10b4933601f9aa9f0ec8f157f","https://git.kernel.org/stable/c/1a770927dc1d642b22417c3e668c871689fc58b3","https://git.kernel.org/stable/c/37fe99016b12d32100ce670216816dba6c48b309","https://git.kernel.org/stable/c/8d95465d9a424200485792858c5b3be54658ce19","https://git.kernel.org/stable/c/afdd29726a6de4ba27cd15590661424c888dc596","https://git.kernel.org/stable/c/d9fefc51133107e59d192d773be86c1150cfeebb","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26719 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. | ["https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0","https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9","https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906","https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0","https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9","https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2162 | Medium | fixed |
|
A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information. | ["https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.spinics.net/lists/linux-scsi/msg181542.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00005.html","https://lists.debian.org/debian-lts-announce/2023/05/msg00006.html","https://www.spinics.net/lists/linux-scsi/msg181542.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26635 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: llc: Drop support for ETH_P_TR_802_2. syzbot reported an uninit-value bug below. [0] llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2 (0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16) llc_conn_handler() initialises local variables {saddr,daddr}.mac based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes them to __llc_lookup(). However, the initialisation is done only when skb->protocol is htons(ETH_P_802_2), otherwise, __llc_lookup_established() and __llc_lookup_listener() will read garbage. The missing initialisation existed prior to commit 211ed865108e ("net: delete all instances of special processing for token ring"). It removed the part to kick out the token ring stuff but forgot to close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv(). Let's remove llc_tr_packet_type and complete the deprecation. [0]: BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b Local variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 | ["https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62","https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6","https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd","https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097","https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828","https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc","https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61","https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8","https://git.kernel.org/stable/c/165ad1e22779685c3ed3dd349c6c4c632309cc62","https://git.kernel.org/stable/c/660c3053d992b68fee893a0e9ec9159228cffdc6","https://git.kernel.org/stable/c/9ccdef19cf9497c2803b005369668feb91cacdfd","https://git.kernel.org/stable/c/b8e8838f82f332ae80c643dbb1ca4418d0628097","https://git.kernel.org/stable/c/c0fe2fe7a5a291dfcf6dc64301732c8d3dc6a828","https://git.kernel.org/stable/c/df57fc2f2abf548aa889a36ab0bdcc94a75399dc","https://git.kernel.org/stable/c/e3f9bed9bee261e3347131764e42aeedf1ffea61","https://git.kernel.org/stable/c/f1f34a515fb1e25e85dee94f781e7869ae351fb8","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26636 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: llc: make llc_ui_sendmsg() more robust against bonding changes syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no headroom, but subsequently trying to push 14 bytes of Ethernet header [1] Like some others, llc_ui_sendmsg() releases the socket lock before calling sock_alloc_send_skb(). Then it acquires it again, but does not redo all the sanity checks that were performed. This fix: - Uses LL_RESERVED_SPACE() to reserve space. - Check all conditions again after socket lock is held again. - Do not account Ethernet header for mtu limitation. [1] skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 sp : ffff800096f97000 x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000 x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2 x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0 x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001 x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400 x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714 x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089 Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595 Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000) | ["https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c","https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4","https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b","https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d","https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249","https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb","https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b","https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647","https://git.kernel.org/stable/c/04f2a74b562f3a7498be0399309669f342793d8c","https://git.kernel.org/stable/c/6d53b813ff8b177f86f149c2f744442681f720e4","https://git.kernel.org/stable/c/84e9d10419f6f4f3f3cd8f9aaf44a48719aa4b1b","https://git.kernel.org/stable/c/b643d0defcbacd7fe548bc65c3e4e6f17dc5eb2d","https://git.kernel.org/stable/c/c22044270da68881074fda81a7d34812726cb249","https://git.kernel.org/stable/c/c451c008f563d56d5e676c9dcafae565fcad84bb","https://git.kernel.org/stable/c/cafd3ad3fe03ef4d6632747be9ee15dc0029db4b","https://git.kernel.org/stable/c/dad555c816a50c6a6a8a86be1f9177673918c647","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26645 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tracing: Ensure visibility when inserting an element into tracing_map Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc) The warning looks as follows: [ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408 [ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracing_map_sort_entries+0x3e0/0x408 [ 2911.195220] hist_show+0x124/0x800 [ 2911.195692] seq_read_iter+0x1d4/0x4e8 [ 2911.196193] seq_read+0xe8/0x138 [ 2911.196638] vfs_read+0xc8/0x300 [ 2911.197078] ksys_read+0x70/0x108 [ 2911.197534] __arm64_sys_read+0x24/0x38 [ 2911.198046] invoke_syscall+0x78/0x108 [ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8 [ 2911.199157] do_el0_svc+0x28/0x40 [ 2911.199613] el0_svc+0x40/0x178 [ 2911.200048] el0t_64_sync_handler+0x13c/0x158 [ 2911.200621] el0t_64_sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]--- The problem appears to be caused by CPU reordering of writes issued from __tracing_map_insert(). The check for the presence of an element with a given key in this function is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ... The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt; The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated--- | ["https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7","https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b","https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7","https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177","https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb","https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c","https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860","https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a","https://git.kernel.org/stable/c/2b44760609e9eaafc9d234a6883d042fc21132a7","https://git.kernel.org/stable/c/5022b331c041e8c54b9a6a3251579bd1e8c0fc0b","https://git.kernel.org/stable/c/a1eebe76e187dbe11ca299f8dbb6e45d5b1889e7","https://git.kernel.org/stable/c/aef1cb00856ccfd614467cfb50b791278992e177","https://git.kernel.org/stable/c/bf4aeff7da85c3becd39fb73bac94122331c30fb","https://git.kernel.org/stable/c/dad9b28f675ed99b4dec261db2a397efeb80b74c","https://git.kernel.org/stable/c/ef70dfa0b1e5084f32635156c9a5c795352ad860","https://git.kernel.org/stable/c/f4f7e696db0274ff560482cc52eddbf0551d4b7a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26805 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]: netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data(). This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects uninitialized memory area when copying the data. This patch resolved this issue by correct the len from `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated--- | ["https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44","https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d","https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd","https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777","https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285","https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736","https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65","https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77","https://git.kernel.org/stable/c/0b27bf4c494d61e5663baa34c3edd7ccebf0ea44","https://git.kernel.org/stable/c/59fc3e3d049e39e7d0d271f20dd5fb47c57faf1d","https://git.kernel.org/stable/c/661779e1fcafe1b74b3f3fe8e980c1e207fea1fd","https://git.kernel.org/stable/c/9ae51361da43270f4ba0eb924427a07e87e48777","https://git.kernel.org/stable/c/c71ed29d15b1a1ed6c464f8c3536996963046285","https://git.kernel.org/stable/c/d3ada42e534a83b618bbc1e490d23bf0fdae4736","https://git.kernel.org/stable/c/ec343a55b687a452f5e87f3b52bf9f155864df65","https://git.kernel.org/stable/c/f19d1f98e60e68b11fc60839105dd02a30ec0d77","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26825 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nfc: nci: free rx_data_reassembly skb on NCI device cleanup rx_data_reassembly skb is stored during NCI data exchange for processing fragmented packets. It is dropped only when the last fragment is processed or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received. However, the NCI device may be deallocated before that which leads to skb leak. As by design the rx_data_reassembly skb is bound to the NCI device and nothing prevents the device to be freed before the skb is processed in some way and cleaned, free it on the NCI device cleanup. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. | ["https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1","https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d","https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23","https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895","https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf","https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81","https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9","https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c","https://git.kernel.org/stable/c/16d3f507b0fa70453dc54550df093d6e9ac630c1","https://git.kernel.org/stable/c/2f6d16f0520d6505241629ee2f5c131b547d5f9d","https://git.kernel.org/stable/c/471c9ede8061357b43a116fa692e70d91941ac23","https://git.kernel.org/stable/c/5c0c5ffaed73cbae6c317374dc32ba6cacc60895","https://git.kernel.org/stable/c/71349abe3aba7fedcab5b3fcd7aa82371fb5ccbf","https://git.kernel.org/stable/c/7e9a8498658b398bf11b8e388005fa54e40aed81","https://git.kernel.org/stable/c/a3d90fb5c23f29ba59c04005ae76c5228cef2be9","https://git.kernel.org/stable/c/bfb007aebe6bff451f7f3a4be19f4f286d0d5d9c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26845 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: scsi: target: core: Add TMF to tmr_list handling An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. | ["https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d","https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf","https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb","https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171","https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25","https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d","https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f","https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a","https://git.kernel.org/stable/c/11f3fe5001ed05721e641f0ecaa7a73b7deb245d","https://git.kernel.org/stable/c/168ed59170de1fd7274080fe102216162d6826cf","https://git.kernel.org/stable/c/36bc5040c863b44af06094b22f1e50059227b9cb","https://git.kernel.org/stable/c/425a571a7e6fc389954cf2564e1edbba3740e171","https://git.kernel.org/stable/c/83ab68168a3d990d5ff39ab030ad5754cbbccb25","https://git.kernel.org/stable/c/a9849b67b4402a12eb35eadc9306c1ef9847d53d","https://git.kernel.org/stable/c/bd508f96b5fef96d8a0ce9cbb211d82bcfc2341f","https://git.kernel.org/stable/c/e717bd412001495f17400bfc09f606f1b594ef5a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26857 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b | ["https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca","https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5","https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74","https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29","https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5","https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c","https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914","https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a","https://git.kernel.org/stable/c/048e16dee1fc609c1c85072ccd70bfd4b5fef6ca","https://git.kernel.org/stable/c/0ece581d2a66e8e488c0d3b3e7b5760dbbfdbdd5","https://git.kernel.org/stable/c/1ca1ba465e55b9460e4e75dec9fff31e708fec74","https://git.kernel.org/stable/c/59d2a4076983303f324557a114cfd5c32e1f6b29","https://git.kernel.org/stable/c/c0b22568a9d8384fd000cc49acb8f74bde40d1b5","https://git.kernel.org/stable/c/c7137900691f5692fe3de54566ea7b30bb35d66c","https://git.kernel.org/stable/c/e431c3227864b5646601c97f5f898d99472f2914","https://git.kernel.org/stable/c/e77e0b0f2a11735c64b105edaee54d6344faca8a","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-37454 | Medium | N/A | An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this. | ["https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5","https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/","https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55","https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57","https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d","https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-37454","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f861765464f43a71462d52026fbddfc858239a5","https://lore.kernel.org/all/00000000000056e02f05dfb6e11a%40google.com/T/","https://syzkaller.appspot.com/bug?extid=26873a72980f8fa8bc55","https://syzkaller.appspot.com/bug?extid=60864ed35b1073540d57","https://syzkaller.appspot.com/bug?extid=61564e5023b7229ec85d"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26697 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix data corruption in dsync block recovery for small block sizes The helper function nilfs_recovery_copy_block() of nilfs_recovery_dsync_blocks(), which recovers data from logs created by data sync writes during a mount after an unclean shutdown, incorrectly calculates the on-page offset when copying repair data to the file's page cache. In environments where the block size is smaller than the page size, this flaw can cause data corruption and leak uninitialized memory bytes during the recovery process. Fix these issues by correcting this byte offset calculation on the page. | ["https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5","https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9","https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d","https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa","https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65","https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1","https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3","https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba","https://git.kernel.org/stable/c/120f7fa2008e3bd8b7680b4ab5df942decf60fd5","https://git.kernel.org/stable/c/2000016bab499074e6248ea85aeea7dd762355d9","https://git.kernel.org/stable/c/2e1480538ef60bfee5473dfe02b1ecbaf1a4aa0d","https://git.kernel.org/stable/c/364a66be2abdcd4fd426ffa44d9b8f40aafb3caa","https://git.kernel.org/stable/c/5278c3eb6bf5896417572b52adb6be9d26e92f65","https://git.kernel.org/stable/c/67b8bcbaed4777871bb0dcc888fb02a614a98ab1","https://git.kernel.org/stable/c/9c9c68d64fd3284f7097ed6ae057c8441f39fcd3","https://git.kernel.org/stable/c/a6efe6dbaaf504f5b3f8a5c3f711fe54e7dda0ba","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26839 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered. | ["https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3","https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7","https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25","https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2","https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a","https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896","https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8","https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b","https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3","https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7","https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25","https://git.kernel.org/stable/c/809aa64ebff51eb170ee31a95f83b2d21efa32e2","https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2adf3670a","https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896","https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8","https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26851 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_h323: Add protection for bmp length out of range UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts that are out of bounds for their data type. vmlinux get_bitmap(b=75) + 712 <net/netfilter/nf_conntrack_h323_asn1.c:0> vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956 <net/netfilter/nf_conntrack_h323_asn1.c:592> vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812 <net/netfilter/nf_conntrack_h323_asn1.c:576> vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216 <net/netfilter/nf_conntrack_h323_asn1.c:814> vmlinux DecodeRasMessage() + 304 <net/netfilter/nf_conntrack_h323_asn1.c:833> vmlinux ras_help() + 684 <net/netfilter/nf_conntrack_h323_main.c:1728> vmlinux nf_confirm() + 188 <net/netfilter/nf_conntrack_proto.c:137> Due to abnormal data in skb->data, the extension bitmap length exceeds 32 when decoding ras message then uses the length to make a shift operation. It will change into negative after several loop. UBSAN load could detect a negative shift as an undefined behaviour and reports exception. So we add the protection to avoid the length exceeding 32. Or else it will return out of range error and stop decoding. | ["https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c","https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591","https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a","https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362","https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416","https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb","https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13","https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc","https://git.kernel.org/stable/c/014a807f1cc9c9d5173c1cd935835553b00d211c","https://git.kernel.org/stable/c/39001e3c42000e7c2038717af0d33c32319ad591","https://git.kernel.org/stable/c/4bafcc43baf7bcf93566394dbd15726b5b456b7a","https://git.kernel.org/stable/c/767146637efc528b5e3d31297df115e85a2fd362","https://git.kernel.org/stable/c/80ee5054435a11c87c9a4f30f1ff750080c96416","https://git.kernel.org/stable/c/98db42191329c679f4ca52bec0b319689e1ad8cb","https://git.kernel.org/stable/c/b3c0f553820516ad4b62a9390ecd28d6f73a7b13","https://git.kernel.org/stable/c/ccd1108b16ab572d9bf635586b0925635dbd6bbc","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3161 | Medium | fixed |
|
A flaw was found in the Framebuffer Console (fbcon) in the Linux Kernel. When providing font->width and font->height greater than 32 to fbcon_set_font, since there are no checks in place, a shift-out-of-bounds occurs leading to undefined behavior and possible denial of service. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2213485","https://github.com/torvalds/linux/commit/2b09d5d364986f724f17001ccfe4126b9b43a0be","https://bugzilla.redhat.com/show_bug.cgi?id=2213485","https://github.com/torvalds/linux/commit/2b09d5d364986f724f17001ccfe4126b9b43a0be"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26863 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hsr: Fix uninit-value access in hsr_get_node() KMSAN reported the following uninit-value access issue [1]: ===================================================== BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 ===================================================== If the packet type ID field in the Ethernet header is either ETH_P_PRP or ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr() reads an invalid value as a sequence number. This causes the above issue. This patch fixes the issue by returning NULL if the Ethernet header is not followed by an HSR tag. | ["https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209","https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122","https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862","https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a","https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428","https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e","https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949","https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6","https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c","https://git.kernel.org/stable/c/09e5cdbe2cc88c3c758927644a3eb02fac317209","https://git.kernel.org/stable/c/1ed222ca7396938eb1ab2d034f1ba0d8b00a7122","https://git.kernel.org/stable/c/39cc316fb3bc5e7c9dc5eed314fe510d119c6862","https://git.kernel.org/stable/c/7fb2d4d6bb1c85f7a23aace0ed6c86a95dea792a","https://git.kernel.org/stable/c/889ed056eae7fda85b769a9ab33c093379c45428","https://git.kernel.org/stable/c/97d2148ea435dff4b4e71817c9032eb321bcd37e","https://git.kernel.org/stable/c/a809bbfd0e503351d3051317288a70a4569a4949","https://git.kernel.org/stable/c/ddbec99f58571301679addbc022256970ca3eac6","https://git.kernel.org/stable/c/e3b2bfb8ff1810a537b2aa55ba906a6743ed120c","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52513 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix connection failure handling In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails. This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state. | ["https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed","https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590","https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f","https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594","https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d","https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8","https://git.kernel.org/stable/c/0d520cdb0cd095eac5d00078dfd318408c9b5eed","https://git.kernel.org/stable/c/53a3f777049771496f791504e7dc8ef017cba590","https://git.kernel.org/stable/c/5cf38e638e5d01b68f9133968a85e8b3fd1ecf2f","https://git.kernel.org/stable/c/6e26812e289b374c17677d238164a5a8f5770594","https://git.kernel.org/stable/c/81b7bf367eea795d259d0261710c6a89f548844d","https://git.kernel.org/stable/c/eeafc50a77f6a783c2c44e7ec3674a7b693e06f8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26644 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't abort filesystem when attempting to snapshot deleted subvolume If the source file descriptor to the snapshot ioctl refers to a deleted subvolume, we get the following abort: BTRFS: Transaction aborted (error -2) WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs] Modules linked in: pata_acpi btrfs ata_piix libata scsi_mod virtio_net blake2b_generic xor net_failover virtio_rng failover scsi_common rng_core raid6_pq libcrc32c CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs] RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027 RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840 RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998 R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80 FS: 00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0 Call Trace: <TASK> ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? __warn+0x81/0x130 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? report_bug+0x171/0x1a0 ? handle_bug+0x3a/0x70 ? exc_invalid_op+0x17/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? create_pending_snapshot+0x1040/0x1190 [btrfs] ? create_pending_snapshot+0x1040/0x1190 [btrfs] create_pending_snapshots+0x92/0xc0 [btrfs] btrfs_commit_transaction+0x66b/0xf40 [btrfs] btrfs_mksubvol+0x301/0x4d0 [btrfs] btrfs_mksnapshot+0x80/0xb0 [btrfs] __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs] btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs] btrfs_ioctl+0x8a6/0x2650 [btrfs] ? kmem_cache_free+0x22/0x340 ? do_sys_openat2+0x97/0xe0 __x64_sys_ioctl+0x97/0xd0 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7fe20abe83af RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58 </TASK> ---[ end trace 0000000000000000 ]--- BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry BTRFS info (device vdc: state EA): forced readonly BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction. BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry This happens because create_pending_snapshot() initializes the new root item as a copy of the source root item. This includes the refs field, which is 0 for a deleted subvolume. The call to btrfs_insert_root() therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then finds the root and returns -ENOENT if refs == 0, which causes create_pending_snapshot() to abort. Fix it by checking the source root's refs before attempting the snapshot, but after locking subvol_sem to avoid racing with deletion. | ["https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c","https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464","https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b","https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a","https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff","https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256","https://git.kernel.org/stable/c/0877497dc97834728e1b528ddf1e1c484292c29c","https://git.kernel.org/stable/c/2bdf872bcfe629a6202ffd6641615a8ed00e8464","https://git.kernel.org/stable/c/6e6bca99e8d88d989a7cde4c064abea552d5219b","https://git.kernel.org/stable/c/7081929ab2572920e94d70be3d332e5c9f97095a","https://git.kernel.org/stable/c/d8680b722f0ff6d7a01ddacc1844e0d52354d6ff","https://git.kernel.org/stable/c/ec794a7528199e1be6d47bec03f4755aa75df256","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26707 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame() Syzkaller reported [1] hitting a warning after failing to allocate resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will not help much in this case, it might be prudent to switch to netdev_warn_once(). At the very least it will suppress syzkaller reports such as [1]. Just in case, use netdev_warn_once() in send_prp_supervision_frame() for similar reasons. [1] HSR: Could not send supervision frame WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294 ... Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649 ... This issue is also found in older kernels (at least up to 5.10). | ["https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb","https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e","https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51","https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a","https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8","https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0","https://git.kernel.org/stable/c/0d8011a878fdf96123bc0d6a12e2fe7ced5fddfb","https://git.kernel.org/stable/c/37e8c97e539015637cb920d3e6f1e404f707a06e","https://git.kernel.org/stable/c/547545e50c913861219947ce490c68a1776b9b51","https://git.kernel.org/stable/c/56440799fc4621c279df16176f83a995d056023a","https://git.kernel.org/stable/c/923dea2a7ea9e1ef5ac4031fba461c1cc92e32b8","https://git.kernel.org/stable/c/de769423b2f053182a41317c4db5a927e90622a0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26787 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mmc: mmci: stm32: fix DMA API overlapping mappings warning Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320 DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced. If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path. | ["https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53","https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4","https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c","https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be","https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef","https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85","https://git.kernel.org/stable/c/0224cbc53ba82b84affa7619b6d1b1a254bc2c53","https://git.kernel.org/stable/c/176e66269f0de327375fc0ea51c12c2f5a97e4c4","https://git.kernel.org/stable/c/5ae5060e17a3fc38e54c3e5bd8abd6b1d5bfae7c","https://git.kernel.org/stable/c/6b1ba3f9040be5efc4396d86c9752cdc564730be","https://git.kernel.org/stable/c/70af82bb9c897faa25a44e4181f36c60312b71ef","https://git.kernel.org/stable/c/d610a307225951929b9dff807788439454476f85","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26795 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: riscv: Sparse-Memory/vmemmap out-of-bounds fix Offset vmemmap so that the first page of vmemmap will be mapped to the first page of physical memory in order to ensure that vmemmap’s bounds will be respected during pfn_to_page()/page_to_pfn() operations. The conversion macros will produce correct SV39/48/57 addresses for every possible/valid DRAM_BASE inside the physical memory limits. v2:Address Alex's comments | ["https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe","https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef","https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af","https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd","https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9","https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e","https://git.kernel.org/stable/c/2a1728c15ec4f45ed9248ae22f626541c179bfbe","https://git.kernel.org/stable/c/5941a90c55d3bfba732b32208d58d997600b44ef","https://git.kernel.org/stable/c/8310080799b40fd9f2a8b808c657269678c149af","https://git.kernel.org/stable/c/8af1c121b0102041809bc137ec600d1865eaeedd","https://git.kernel.org/stable/c/a11dd49dcb9376776193e15641f84fcc1e5980c9","https://git.kernel.org/stable/c/a278d5c60f21aa15d540abb2f2da6e6d795c3e6e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4459 | Medium | fixed |
|
A NULL pointer dereference flaw was found in vmxnet3_rq_cleanup in drivers/net/vmxnet3/vmxnet3_drv.c in the networking sub-component in vmxnet3 in the Linux Kernel. This issue may allow a local attacker with normal user privilege to cause a denial of service due to a missing sanity check during cleanup. | ["https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-4459","https://bugzilla.redhat.com/show_bug.cgi?id=2219268","https://github.com/torvalds/linux/commit/edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd","https://access.redhat.com/errata/RHSA-2024:0412","https://access.redhat.com/errata/RHSA-2024:1250","https://access.redhat.com/errata/RHSA-2024:1306","https://access.redhat.com/errata/RHSA-2024:1367","https://access.redhat.com/errata/RHSA-2024:1382","https://access.redhat.com/errata/RHSA-2024:2006","https://access.redhat.com/errata/RHSA-2024:2008","https://access.redhat.com/security/cve/CVE-2023-4459","https://bugzilla.redhat.com/show_bug.cgi?id=2219268","https://github.com/torvalds/linux/commit/edf410cb74dc612fd47ef5be319c5a0bcd6e6ccd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26833 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix memory leak in dm_sw_fini() After destroying dmub_srv, the memory associated with it is not freed, causing a memory leak: unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [<ffffffff993495ed>] kmalloc_trace+0x29d/0x340 [<ffffffffc0ea4a94>] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [<ffffffffc0ea4e55>] dm_sw_init+0x15/0x2b0 [amdgpu] [<ffffffffc0ba8557>] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [<ffffffffc0bab285>] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [<ffffffffc0ba09c7>] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [<ffffffff9968fd1e>] local_pci_probe+0x3e/0x90 [<ffffffff996918a3>] pci_device_probe+0xc3/0x230 [<ffffffff99805872>] really_probe+0xe2/0x480 [<ffffffff99805c98>] __driver_probe_device+0x78/0x160 [<ffffffff99805daf>] driver_probe_device+0x1f/0x90 [<ffffffff9980601e>] __driver_attach+0xce/0x1c0 [<ffffffff99803170>] bus_for_each_dev+0x70/0xc0 [<ffffffff99804822>] bus_add_driver+0x112/0x210 [<ffffffff99807245>] driver_register+0x55/0x100 [<ffffffff990012d1>] do_one_initcall+0x41/0x300 Fix this by freeing dmub_srv after destroying it. | ["https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2","https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e","https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b","https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30","https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857","https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3","https://git.kernel.org/stable/c/10c6b90e975358c17856a578419dc449887899c2","https://git.kernel.org/stable/c/33f649f1b1cea39ed360e6c12bba4fac83118e6e","https://git.kernel.org/stable/c/541e79265ea7e339a7c4a462feafe9f8f996e04b","https://git.kernel.org/stable/c/58168005337eabef345a872be3f87d0215ff3b30","https://git.kernel.org/stable/c/b49b022f7dfce85eb77d0d987008fde5c01d7857","https://git.kernel.org/stable/c/bae67893578d608e35691dcdfa90c4957debf1d3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-48627 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. | ["https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265","https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc","https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244","https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c","https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926","https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29","https://git.kernel.org/stable/c/14d2cc21ca622310babf373e3a8f0b40acfe8265","https://git.kernel.org/stable/c/39cdb68c64d84e71a4a717000b6e5de208ee60cc","https://git.kernel.org/stable/c/57964a5710252bc82fe22d9fa98c180c58c20244","https://git.kernel.org/stable/c/815be99d934e3292906536275f2b8d5131cdf52c","https://git.kernel.org/stable/c/bfee93c9a6c395f9aa62268f1cedf64999844926","https://git.kernel.org/stable/c/c8686c014b5e872ba7e334f33ca553f14446fc29","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52498 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false. | ["https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557","https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7","https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0","https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34","https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe","https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d","https://git.kernel.org/stable/c/7839d0078e0d5e6cc2fa0b0dfbee71de74f1e557","https://git.kernel.org/stable/c/9bd3dce27b01c51295b60e1433e1dadfb16649f7","https://git.kernel.org/stable/c/a1d62c775b07213c73f81ae842424c74dd14b5f0","https://git.kernel.org/stable/c/e1c9d32c98309ae764893a481552d3f99d46cb34","https://git.kernel.org/stable/c/e681e29d1f59a04ef773296e4bebb17b1b79f8fe","https://git.kernel.org/stable/c/f46eb832389f162ad13cb780d0b8cde93641990d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2025-21684 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: Convert gpio_lock to raw spinlock irq_chip functions may be called in raw spinlock context. Therefore, we must also use a raw spinlock for our own internal locking. This fixes the following lockdep splat: [ 5.349336] ============================= [ 5.353349] [ BUG: Invalid wait context ] [ 5.357361] 6.13.0-rc5+ #69 Tainted: G W [ 5.363031] ----------------------------- [ 5.367045] kworker/u17:1/44 is trying to lock: [ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.380079] other info that might help us debug this: [ 5.385138] context-{5:5} [ 5.387762] 5 locks held by kworker/u17:1/44: [ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204) [ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205) [ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006) [ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596) [ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614) [ 5.436472] stack backtrace: [ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69 [ 5.448690] Tainted: [W]=WARN [ 5.451656] Hardware name: xlnx,zynqmp (DT) [ 5.455845] Workqueue: events_unbound deferred_probe_work_func [ 5.461699] Call trace: [ 5.464147] show_stack+0x18/0x24 C [ 5.467821] dump_stack_lvl (lib/dump_stack.c:123) [ 5.471501] dump_stack (lib/dump_stack.c:130) [ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176) [ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814) [ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8)) [ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345) [ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250) [ 5.497645] irq_startup (kernel/irq/chip.c:270) [ 5.501143] __setup_irq (kernel/irq/manage.c:1807) [ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208) | ["https://git.kernel.org/stable/c/9860370c2172704b6b4f0075a0c2a29fd84af96a","https://git.kernel.org/stable/c/9c035105c5537d2ecad6b9415e9417a1ffbd0a62","https://git.kernel.org/stable/c/b0111650ee596219bb5defa0ce1a1308e6e77ccf","https://git.kernel.org/stable/c/d25041d4a3b2af64c888cf762362b2528ba59294","https://git.kernel.org/stable/c/f0ed2d0abc021f56fa27dc6d0770535c1851a43b"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52527 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don't want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when 'copy' is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn't. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds the UDP packet itself. | ["https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6","https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59","https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844","https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed","https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070","https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb","https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f","https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd","https://git.kernel.org/stable/c/1fc793d68d50dee4782ef2e808913d5dd880bcc6","https://git.kernel.org/stable/c/559d697c5d072593d22b3e0bd8b8081108aeaf59","https://git.kernel.org/stable/c/7626b9fed53092aa2147978070e610ecb61af844","https://git.kernel.org/stable/c/96b2e1090397217839fcd6c9b6d8f5d439e705ed","https://git.kernel.org/stable/c/9d4c75800f61e5d75c1659ba201b6c0c7ead3070","https://git.kernel.org/stable/c/cd1189956393bf850b2e275e37411855d3bd86bb","https://git.kernel.org/stable/c/f6a7182179c0ed788e3755ee2ed18c888ddcc33f","https://git.kernel.org/stable/c/fe80658c08e3001c80c5533cd41abfbb0e0e28fd"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52528 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. | ["https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed","https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5","https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825","https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4","https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d","https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09","https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812","https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8","https://git.kernel.org/stable/c/2a36d9e2995c8c3c3f179aab1215a69cff06cbed","https://git.kernel.org/stable/c/30bc4d7aebe33904b0f2d3aad4b4a9c6029ad0c5","https://git.kernel.org/stable/c/310f1c92f65ad905b7e81fe14de82d979ebbd825","https://git.kernel.org/stable/c/3e0af6eec1789fd11934164a7f4dbcad979855a4","https://git.kernel.org/stable/c/4931e80da9463b03bfe42be54a9a19f213b0f76d","https://git.kernel.org/stable/c/9ffc5018020fe646795a8dc1203224b8f776dc09","https://git.kernel.org/stable/c/cda10784a176d7192f08ecb518f777a4e9575812","https://git.kernel.org/stable/c/e9c65989920f7c28775ec4e0c11b483910fb67b8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26788 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: init irq after reg initialization Initialize the qDMA irqs after the registers are configured so that interrupts that may have been pending from a primary kernel don't get processed by the irq handler before it is ready to and cause panic with the following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18 | ["https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478","https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b","https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99","https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8","https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd","https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1","https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d","https://git.kernel.org/stable/c/3cc5fb824c2125aa3740d905b3e5b378c8a09478","https://git.kernel.org/stable/c/4529c084a320be78ff2c5e64297ae998c6fdf66b","https://git.kernel.org/stable/c/474d521da890b3e3585335fb80a6044cb2553d99","https://git.kernel.org/stable/c/677102a930643c31f1b4c512b041407058bdfef8","https://git.kernel.org/stable/c/87a39071e0b639f45e05d296cc0538eef44ec0bd","https://git.kernel.org/stable/c/9579a21e99fe8dab22a253050ddff28d340d74e1","https://git.kernel.org/stable/c/a69c8bbb946936ac4eb6a6ae1e849435aa8d947d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52566 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log] | ["https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33","https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2","https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8","https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7","https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc","https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c","https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b","https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1","https://git.kernel.org/stable/c/193b5a1c6c67c36b430989dc063fe7ea4e200a33","https://git.kernel.org/stable/c/28df4646ad8b433340772edc90ca709cdefc53e2","https://git.kernel.org/stable/c/3936e8714907cd55e37c7cc50e50229e4a9042e8","https://git.kernel.org/stable/c/7130a87ca32396eb9bf48b71a2d42259ae44c6c7","https://git.kernel.org/stable/c/7ee29facd8a9c5a26079148e36bcf07141b3a6bc","https://git.kernel.org/stable/c/980663f1d189eedafd18d80053d9cf3e2ceb5c8c","https://git.kernel.org/stable/c/bb61224f6abc8e71bfdf06d7c984e23460875f5b","https://git.kernel.org/stable/c/fb1084e63ee56958b0a56e17a50a4fd86445b9c1"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26702 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC Recently, we encounter kernel crash in function rm3100_common_probe caused by out of bound access of array rm3100_samp_rates (because of underlying hardware failures). Add boundary check to prevent out of bound access. | ["https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513","https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01","https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56","https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1","https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481","https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e","https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60","https://git.kernel.org/stable/c/176256ff8abff29335ecff905a09fb49e8dcf513","https://git.kernel.org/stable/c/1d8c67e94e9e977603473a543d4f322cf2c4aa01","https://git.kernel.org/stable/c/36a49290d7e6d554020057a409747a092b1d3b56","https://git.kernel.org/stable/c/57d05dbbcd0b3dc0c252103b43012eef5d6430d1","https://git.kernel.org/stable/c/7200170e88e3ec54d9e9c63f07514c3cead11481","https://git.kernel.org/stable/c/792595bab4925aa06532a14dd256db523eb4fa5e","https://git.kernel.org/stable/c/8d5838a473e8e6d812257c69745f5920e4924a60","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26903 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD` packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point 2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling rfcomm_recv_frame in rfcomm_process_rx. | ["https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26","https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b","https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5","https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73","https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85","https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd","https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96","https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0","https://git.kernel.org/stable/c/2535b848fa0f42ddff3e5255cf5e742c9b77bb26","https://git.kernel.org/stable/c/369f419c097e82407dd429a202cde9a73d3ae29b","https://git.kernel.org/stable/c/3ead59bafad05f2967ae2438c0528d53244cfde5","https://git.kernel.org/stable/c/567c0411dc3b424fc7bd1e6109726d7ba32d4f73","https://git.kernel.org/stable/c/5f369efd9d963c1f711a06c9b8baf9f5ce616d85","https://git.kernel.org/stable/c/5f9fe302dd3a9bbc50f4888464c1773f45166bfd","https://git.kernel.org/stable/c/81d7d920a22fd58ef9aedb1bd0a68ee32bd23e96","https://git.kernel.org/stable/c/8d1753973f598531baaa2c1033cf7f7b5bb004b0","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2166 | Medium | fixed |
|
A null pointer dereference issue was found in can protocol in net/can/af_can.c in the Linux before Linux. ml_priv may not be initialized in the receive path of CAN frames. A local user could use this flaw to crash the system or potentially cause a denial of service. | ["https://lore.kernel.org/lkml/CAO4mrfcV_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w%40mail.gmail.com/","https://lore.kernel.org/lkml/CAO4mrfcV_07hbj8NUuZrA8FH-kaRsrFy-2metecpTuE5kKHn5w%40mail.gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-28327 | Medium | fixed |
|
A NULL pointer dereference flaw was found in the UNIX protocol in net/unix/diag.c In unix_diag_get_exact in the Linux Kernel. The newly allocated skb does not have sk, leading to a NULL pointer. This flaw allows a local user to crash or potentially cause a denial of service. | ["https://bugzilla.redhat.com/show_bug.cgi?id=2177382","https://bugzilla.redhat.com/show_bug.cgi?id=2177382"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26779 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit after inserting a sta. | ["https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9","https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954","https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd","https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587","https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5","https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d","https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f","https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696","https://git.kernel.org/stable/c/281280276b70c822f55ce15b661f6d1d3228aaa9","https://git.kernel.org/stable/c/54b79d8786964e2f840e8a2ec4a9f9a50f3d4954","https://git.kernel.org/stable/c/5ffab99e070b9f8ae0cf60c3c3602b84eee818dd","https://git.kernel.org/stable/c/76fad1174a0cae6fc857b9f88b261a2e4f07d587","https://git.kernel.org/stable/c/85720b69aef177318f4a18efbcc4302228a340e5","https://git.kernel.org/stable/c/88c18fd06608b3adee547102505d715f21075c9d","https://git.kernel.org/stable/c/bcbc84af1183c8cf3d1ca9b78540c2185cd85e7f","https://git.kernel.org/stable/c/eb39bb548bf974acad7bd6780fe11f9e6652d696","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-25739 | Medium | N/A | create_empty_lvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->leb_size. | ["https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9","https://groups.google.com/g/syzkaller/c/Xl97YcQA4hg","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://web.git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/mtd/ubi/vtbl.c?h=v6.6.24\u0026id=d1b505c988b7","https://www.spinics.net/lists/kernel/msg5074816.html","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=68a24aba7c593eafa8fd00f2f76407b9b32b47a9","https://groups.google.com/g/syzkaller/c/Xl97YcQA4hg","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://www.spinics.net/lists/kernel/msg5074816.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-25741 | Medium | N/A | printer_write in drivers/usb/gadget/function/f_printer.c in the Linux kernel through 6.7.4 does not properly call usb_ep_queue, which might allow attackers to cause a denial of service or have unspecified other impact. | ["https://www.spinics.net/lists/linux-usb/msg252167.html","https://www.spinics.net/lists/linux-usb/msg252167.html"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52477 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. | ["https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289","https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c","https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b","https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3","https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d","https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81","https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee","https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81","https://git.kernel.org/stable/c/136f69a04e71ba3458d137aec3bb2ce1232c0289","https://git.kernel.org/stable/c/241f230324337ed5eae3846a554fb6d15169872c","https://git.kernel.org/stable/c/528f0ba9f7a4bc1b61c9b6eb591ff97ca37cac6b","https://git.kernel.org/stable/c/6ad3e9fd3632106696692232bf7ff88b9f7e1bc3","https://git.kernel.org/stable/c/8e7346bfea56453e31b7421c1c17ca2fb9ed613d","https://git.kernel.org/stable/c/c64e4dca9aefd232b17ac4c779b608b286654e81","https://git.kernel.org/stable/c/f74a7afc224acd5e922c7a2e52244d891bbe44ee","https://git.kernel.org/stable/c/fb9895ab9533534335fa83d70344b397ac862c81"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52484 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. | ["https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429","https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6","https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b","https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264","https://git.kernel.org/stable/c/3283a1bce9bbc978059f790b84f3c10c32492429","https://git.kernel.org/stable/c/d5afb4b47e13161b3f33904d45110f9e6463bad6","https://git.kernel.org/stable/c/f5a604757aa8e37ea9c7011dc9da54fa1b30f29b","https://git.kernel.org/stable/c/f90f4c562003ac3d3b135c5a40a5383313f27264"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0639 | Medium | N/A | A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel’s SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system. | ["https://access.redhat.com/security/cve/CVE-2024-0639","https://bugzilla.redhat.com/show_bug.cgi?id=2258754","https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a","https://access.redhat.com/security/cve/CVE-2024-0639","https://bugzilla.redhat.com/show_bug.cgi?id=2258754","https://github.com/torvalds/linux/commit/6feb37b3b06e9049e20dcf7e23998f92c9c5be9a"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0641 | Medium | fixed |
|
A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel’s TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system. | ["https://access.redhat.com/security/cve/CVE-2024-0641","https://bugzilla.redhat.com/show_bug.cgi?id=2258757","https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5","https://access.redhat.com/security/cve/CVE-2024-0641","https://bugzilla.redhat.com/show_bug.cgi?id=2258757","https://github.com/torvalds/linux/commit/08e50cf071847323414df0835109b6f3560d44f5"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3863 | Medium | fixed |
|
A use-after-free flaw was found in nfc_llcp_find_local in net/nfc/llcp_core.c in NFC in the Linux kernel. This flaw allows a local user with special privileges to impact a kernel information leak issue. | ["https://access.redhat.com/security/cve/CVE-2023-3863","https://bugzilla.redhat.com/show_bug.cgi?id=2225126","https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492","https://access.redhat.com/security/cve/CVE-2023-3863","https://bugzilla.redhat.com/show_bug.cgi?id=2225126","https://github.com/torvalds/linux/commit/6709d4b7bc2e079241fdef15d1160581c5261c10","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://security.netapp.com/advisory/ntap-20240202-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-39194 | Medium | fixed |
|
A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAP_NET_ADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39194","https://bugzilla.redhat.com/show_bug.cgi?id=2226788","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/errata/RHSA-2024:2950","https://access.redhat.com/errata/RHSA-2024:3138","https://access.redhat.com/security/cve/CVE-2023-39194","https://bugzilla.redhat.com/show_bug.cgi?id=2226788","https://lists.debian.org/debian-lts-announce/2024/01/msg00004.html","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18111/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26861 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wireguard: receive: annotate data-race around receiving_counter.counter Syzkaller with KCSAN identified a data-race issue when accessing keypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE() annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ... | ["https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6","https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce","https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b","https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3","https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0","https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc","https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed","https://git.kernel.org/stable/c/3f94da807fe1668b9830f0eefbbf7e887b0a7bc6","https://git.kernel.org/stable/c/45a83b220c83e3c326513269afbf69ae6fc65cce","https://git.kernel.org/stable/c/78739d72f16b2d7d549f713f1dfebd678d32484b","https://git.kernel.org/stable/c/bba045dc4d996d03dce6fe45726e78a1a1f6d4c3","https://git.kernel.org/stable/c/d691be84ab898cf136a35176eaf2f8fc116563f0","https://git.kernel.org/stable/c/f87884e0dffd61b47e58bc6e1e2f6843c212b0cc","https://git.kernel.org/stable/c/fdf16de078a97bf14bb8ee2b8d47cc3d3ead09ed","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52608 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Check mailbox/SMT channel for consistency On reception of a completion interrupt the shared memory area is accessed to retrieve the message header at first and then, if the message sequence number identifies a transaction which is still pending, the related payload is fetched too. When an SCMI command times out the channel ownership remains with the platform until eventually a late reply is received and, as a consequence, any further transmission attempt remains pending, waiting for the channel to be relinquished by the platform. Once that late reply is received the channel ownership is given back to the agent and any pending request is then allowed to proceed and overwrite the SMT area of the just delivered late reply; then the wait for the reply to the new request starts. It has been observed that the spurious IRQ related to the late reply can be wrongly associated with the freshly enqueued request: when that happens the SCMI stack in-flight lookup procedure is fooled by the fact that the message header now present in the SMT area is related to the new pending transaction, even though the real reply has still to arrive. This race-condition on the A2P channel can be detected by looking at the channel status bits: a genuine reply from the platform will have set the channel free bit before triggering the completion IRQ. Add a consistency check to validate such condition in the A2P ISR. | ["https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda","https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306","https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d","https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350","https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2","https://git.kernel.org/stable/c/12dc4217f16551d6dee9cbefc23fdb5659558cda","https://git.kernel.org/stable/c/437a310b22244d4e0b78665c3042e5d1c0f45306","https://git.kernel.org/stable/c/614cc65032dcb0b64d23f5c5e338a8a04b12be5d","https://git.kernel.org/stable/c/7f95f6997f4fdd17abec3200cae45420a5489350","https://git.kernel.org/stable/c/9b5e1b93c83ee5fc9f5d7bd2d45b421bd87774a2"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52645 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: pmdomain: mediatek: fix race conditions with genpd If the power domains are registered first with genpd and *after that* the driver attempts to power them on in the probe sequence, then it is possible that a race condition occurs if genpd tries to power them on in the same time. The same is valid for powering them off before unregistering them from genpd. Attempt to fix race conditions by first removing the domains from genpd and *after that* powering down domains. Also first power up the domains and *after that* register them to genpd. | ["https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff","https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b","https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438","https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5","https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25","https://git.kernel.org/stable/c/339ddc983bc1622341d95f244c361cda3da3a4ff","https://git.kernel.org/stable/c/3cd1d92ee1dbf3e8f988767eb75f26207397792b","https://git.kernel.org/stable/c/475426ad1ae0bfdfd8f160ed9750903799392438","https://git.kernel.org/stable/c/c41336f4d69057cbf88fed47951379b384540df5","https://git.kernel.org/stable/c/f83b9abee9faa4868a6fac4669b86f4c215dae25"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26837 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. Since only a single delete notification is sent, the count remains at 1 when the bridge is destroyed. Then add the same port (or another port belonging to the same hardware domain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1 All multicast, including the two IPv6 groups from br0, should now be flooded, according to the policy of br1. But instead the old memberships are still active in the hardware database, causing the switch to only forward traffic to those groups towards the CPU (port 0). Eliminate the race in two steps: 1. Grab the write-side lock of the MDB while generating the replay list. This prevents new memberships from showing up while we are generating the replay list. But it leaves the scenario in which a deferred event was already generated, but not delivered, before we grabbed the lock. Therefore: 2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions. | ["https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f","https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db","https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b","https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8","https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f","https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db","https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b","https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52489 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: mm/sparsemem: fix race in accessing memory_section->usage The below race is observed on a PFN which falls into the device memory region with the system memory configuration where PFN's are such that [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL]. Since normal zone start and end pfn contains the device memory PFN's as well, the compaction triggered will try on the device memory PFN's too though they end up in NOP(because pfn_to_online_page() returns NULL for ZONE_DEVICE memory sections). When from other core, the section mappings are being removed for the ZONE_DEVICE region, that the PFN in question belongs to, on which compaction is currently being operated is resulting into the kernel crash with CONFIG_SPASEMEM_VMEMAP enabled. The crash logs can be seen at [1]. compact_zone() memunmap_pages ------------- --------------- __pageblock_pfn_to_page ...... (a)pfn_valid(): valid_section()//return true (b)__remove_pages()-> sparse_remove_section()-> section_deactivate(): [Free the array ms->usage and set ms->usage = NULL] pfn_section_valid() [Access ms->usage which is NULL] NOTE: From the above it can be said that the race is reduced to between the pfn_valid()/pfn_section_valid() and the section deactivate with SPASEMEM_VMEMAP enabled. The commit b943f045a9af("mm/sparse: fix kernel crash with pfn_section_valid check") tried to address the same problem by clearing the SECTION_HAS_MEM_MAP with the expectation of valid_section() returns false thus ms->usage is not accessed. Fix this issue by the below steps: a) Clear SECTION_HAS_MEM_MAP before freeing the ->usage. b) RCU protected read side critical section will either return NULL when SECTION_HAS_MEM_MAP is cleared or can successfully access ->usage. c) Free the ->usage with kfree_rcu() and set ms->usage = NULL. No attempt will be made to access ->usage after this as the SECTION_HAS_MEM_MAP is cleared thus valid_section() return false. Thanks to David/Pavan for their inputs on this patch. [1] https://lore.kernel.org/linux-mm/994410bb-89aa-d987-1f50-f514903c55aa@quicinc.com/ On Snapdragon SoC, with the mentioned memory configuration of PFN's as [ZONE_NORMAL ZONE_DEVICE ZONE_NORMAL], we are able to see bunch of issues daily while testing on a device farm. For this particular issue below is the log. Though the below log is not directly pointing to the pfn_section_valid(){ ms->usage;}, when we loaded this dump on T32 lauterbach tool, it is pointing. [ 540.578056] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 540.578068] Mem abort info: [ 540.578070] ESR = 0x0000000096000005 [ 540.578073] EC = 0x25: DABT (current EL), IL = 32 bits [ 540.578077] SET = 0, FnV = 0 [ 540.578080] EA = 0, S1PTW = 0 [ 540.578082] FSC = 0x05: level 1 translation fault [ 540.578085] Data abort info: [ 540.578086] ISV = 0, ISS = 0x00000005 [ 540.578088] CM = 0, WnR = 0 [ 540.579431] pstate: 82400005 (Nzcv daif +PAN -UAO +TCO -DIT -SSBSBTYPE=--) [ 540.579436] pc : __pageblock_pfn_to_page+0x6c/0x14c [ 540.579454] lr : compact_zone+0x994/0x1058 [ 540.579460] sp : ffffffc03579b510 [ 540.579463] x29: ffffffc03579b510 x28: 0000000000235800 x27:000000000000000c [ 540.579470] x26: 0000000000235c00 x25: 0000000000000068 x24:ffffffc03579b640 [ 540.579477] x23: 0000000000000001 x22: ffffffc03579b660 x21:0000000000000000 [ 540.579483] x20: 0000000000235bff x19: ffffffdebf7e3940 x18:ffffffdebf66d140 [ 540.579489] x17: 00000000739ba063 x16: 00000000739ba063 x15:00000000009f4bff [ 540.579495] x14: 0000008000000000 x13: 0000000000000000 x12:0000000000000001 [ 540.579501] x11: 0000000000000000 x10: 0000000000000000 x9 :ffffff897d2cd440 [ 540.579507] x8 : 0000000000000000 x7 : 0000000000000000 x6 :ffffffc03579b5b4 [ 540.579512] x5 : 0000000000027f25 x4 : ffffffc03579b5b8 x3 :0000000000000 ---truncated--- | ["https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7","https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800","https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a","https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97","https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea","https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529","https://git.kernel.org/stable/c/3a01daace71b521563c38bbbf874e14c3e58adb7","https://git.kernel.org/stable/c/5ec8e8ea8b7783fab150cf86404fc38cb4db8800","https://git.kernel.org/stable/c/68ed9e33324021e9d6b798e9db00ca3093d2012a","https://git.kernel.org/stable/c/70064241f2229f7ba7b9599a98f68d9142e81a97","https://git.kernel.org/stable/c/90ad17575d26874287271127d43ef3c2af876cea","https://git.kernel.org/stable/c/b448de2459b6d62a53892487ab18b7d823ff0529","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52502 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. | ["https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93","https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9","https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d","https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c","https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8","https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc","https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a","https://git.kernel.org/stable/c/31c07dffafce914c1d1543c135382a11ff058d93","https://git.kernel.org/stable/c/6ac22ecdaad2ecc662048f8c6b0ceb1ca0699ef9","https://git.kernel.org/stable/c/7adcf014bda16cdbf804af5c164d94d5d025db2d","https://git.kernel.org/stable/c/d1af8a39cf839d93c8967fdd858f6bbdc3e4a15c","https://git.kernel.org/stable/c/d888d3f70b0de32b4f51534175f039ddab15eef8","https://git.kernel.org/stable/c/e4f2611f07c87b3ddb57c4b9e8efcd1e330fc3dc","https://git.kernel.org/stable/c/e863f5720a5680e50c4cecf12424d7cc31b3eb0a"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-39842 | Medium | fixed |
|
An issue was discovered in the Linux kernel before 5.19. In pxa3xx_gcu_write in drivers/video/fbdev/pxa3xx-gcu.c, the count parameter has a type conflict of size_t versus int, causing an integer overflow and bypassing the size check. After that, because it is used as the third argument to copy_from_user(), a heap overflow may occur. NOTE: the original discoverer disputes that the overflow can actually happen. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/","https://www.debian.org/security/2022/dsa-5257","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.19","https://github.com/torvalds/linux/commit/a09d2d00af53b43c6f11e6ab3cb58443c2cac8a7","https://lists.debian.org/debian-lts-announce/2022/10/msg00000.html","https://lists.debian.org/debian-lts-announce/2022/11/msg00001.html","https://lore.kernel.org/all/YylaC1wHHyLw22D3%40kadam/T/","https://www.debian.org/security/2022/dsa-5257"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26843 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: efi: runtime: Fix potential overflow of soft-reserved region size md_size will have been narrowed if we have >= 4GB worth of pages in a soft-reserved region. | ["https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0","https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9","https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426","https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be","https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70","https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4","https://git.kernel.org/stable/c/156cb12ffdcf33883304f0db645e1eadae712fe0","https://git.kernel.org/stable/c/4aa36b62c3eaa869860bf78b1146e9f2b5f782a9","https://git.kernel.org/stable/c/4fff3d735baea104017f2e3c245e27cdc79f2426","https://git.kernel.org/stable/c/700c3f642c32721f246e09d3a9511acf40ae42be","https://git.kernel.org/stable/c/cf3d6813601fe496de7f023435e31bfffa74ae70","https://git.kernel.org/stable/c/de1034b38a346ef6be25fe8792f5d1e0684d5ff4","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2860 | Medium | N/A | An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel. | ["https://access.redhat.com/security/cve/CVE-2023-2860","https://bugzilla.redhat.com/show_bug.cgi?id=2218122","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511","https://access.redhat.com/security/cve/CVE-2023-2860","https://bugzilla.redhat.com/show_bug.cgi?id=2218122","https://www.zerodayinitiative.com/advisories/ZDI-CAN-18511"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52492 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fix NULL pointer in channel unregistration function __dma_async_device_channel_register() can fail. In case of failure, chan->local is freed (with free_percpu()), and chan->local is nullified. When dma_async_device_unregister() is called (because of managed API or intentionally by DMA controller driver), channels are unconditionally unregistered, leading to this NULL pointer: [ 1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 [...] [ 1.484499] Call trace: [ 1.486930] device_del+0x40/0x394 [ 1.490314] device_unregister+0x20/0x7c [ 1.494220] __dma_async_device_channel_unregister+0x68/0xc0 Look at dma_async_device_register() function error path, channel device unregistration is done only if chan->local is not NULL. Then add the same condition at the beginning of __dma_async_device_channel_unregister() function, to avoid NULL pointer issue whatever the API used to reach this function. | ["https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79","https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08","https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b","https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0","https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17","https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7","https://git.kernel.org/stable/c/047fce470412ab64cb7345f9ff5d06919078ad79","https://git.kernel.org/stable/c/2ab32986a0b9e329eb7f8f04dd57cc127f797c08","https://git.kernel.org/stable/c/7f0ccfad2031eddcc510caf4e57f2d4aa2d8a50b","https://git.kernel.org/stable/c/9263fd2a63487c6d04cbb7b74a48fb12e1e352d0","https://git.kernel.org/stable/c/9de69732dde4e443c1c7f89acbbed2c45a6a8e17","https://git.kernel.org/stable/c/f5c24d94512f1b288262beda4d3dcb9629222fc7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52574 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: team: fix null-ptr-deref when team device type is changed Get a null-ptr-deref bug as follows with reproducer [1]. BUG: kernel NULL pointer dereference, address: 0000000000000228 ... RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] ... Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1] $ teamd -t team0 -d -c '{"runner": {"name": "loadbalance"}}' $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 When enslave a vlan device to team device and team device type is changed from non-ether to ether, header_ops of team device is changed to vlan_header_ops. That is incorrect and will trigger null-ptr-deref for vlan->real_dev in vlan_dev_hard_header() because team device is not a vlan device. Cache eth_header_ops in team_setup(), then assign cached header_ops to header_ops of team net device when its type is changed from non-ether to ether to fix the bug. | ["https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457","https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58","https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd","https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7","https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7","https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d","https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d","https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255","https://git.kernel.org/stable/c/1779eb51b9cc628cee551f252701a85a2a50a457","https://git.kernel.org/stable/c/2f0acb0736ecc3eb85dc80ad2790d634dcb10b58","https://git.kernel.org/stable/c/492032760127251e5540a5716a70996bacf2a3fd","https://git.kernel.org/stable/c/a7fb47b9711101d2405b0eb1276fb1f9b9b270c7","https://git.kernel.org/stable/c/b44dd92e2afd89eb6e9d27616858e72a67bdc1a7","https://git.kernel.org/stable/c/c5f6478686bb45f453031594ae19b6c9723a780d","https://git.kernel.org/stable/c/cac50d9f5d876be32cb9aa21c74018468900284d","https://git.kernel.org/stable/c/cd05eec2ee0cc396813a32ef675634e403748255"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52587 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: IB/ipoib: Fix mcast list locking Releasing the `priv->lock` while iterating the `priv->multicast_list` in `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to remove the items while in the middle of iteration. If the mcast is removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below) -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups. crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2" -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967 crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0" -- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff ---truncated--- | ["https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18","https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825","https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9","https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a","https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90","https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89","https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2","https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34","https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18","https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825","https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9","https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a","https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90","https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89","https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2","https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-2985 | Medium | fixed |
|
A use after free flaw was found in hfsplus_put_super in fs/hfsplus/super.c in the Linux Kernel. This flaw could allow a local user to cause a denial of service problem. | ["https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07db5e247ab5858439b14dd7cc1fe538b9efcf32","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=07db5e247ab5858439b14dd7cc1fe538b9efcf32"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52615 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hwrng: core - Fix page fault dead lock on mmap-ed hwrng There is a dead-lock in the hwrng device read path. This triggers when the user reads from /dev/hwrng into memory also mmap-ed from /dev/hwrng. The resulting page fault triggers a recursive read which then dead-locks. Fix this by using a stack buffer when calling copy_to_user. | ["https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0","https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48","https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029","https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922","https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e","https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c","https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990","https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d","https://git.kernel.org/stable/c/26cc6d7006f922df6cc4389248032d955750b2a0","https://git.kernel.org/stable/c/5030d4c798863ccb266563201b341a099e8cdd48","https://git.kernel.org/stable/c/6822a14271786150e178869f1495cc03e74c5029","https://git.kernel.org/stable/c/78aafb3884f6bc6636efcc1760c891c8500b9922","https://git.kernel.org/stable/c/aa8aa16ed9adf1df05bb339d588cf485a011839e","https://git.kernel.org/stable/c/c6a8111aacbfe7a8a70f46cc0de8eed00561693c","https://git.kernel.org/stable/c/eafd83b92f6c044007a3591cbd476bcf90455990","https://git.kernel.org/stable/c/ecabe8cd456d3bf81e92c53b074732f3140f170d","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52486 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many times by mistake due to deadlock handling If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit. | ["https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229","https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0","https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7","https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551","https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a","https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c","https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c","https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105","https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229","https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0","https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7","https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551","https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a","https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c","https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c","https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-4194 | Medium | N/A | A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4194","https://bugzilla.redhat.com/show_bug.cgi?id=2229498","https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/security/cve/CVE-2023-4194","https://bugzilla.redhat.com/show_bug.cgi?id=2229498","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/344H6HO6SSC4KT7PDFXSDIXKMKHISSGF/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/3TYLSJ2SAI7RF56ZLQ5CQWCJLVJSD73Q/","https://lore.kernel.org/all/20230731164237.48365-1-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-2-lersek@redhat.com/","https://lore.kernel.org/all/20230731164237.48365-3-lersek@redhat.com/","https://security.netapp.com/advisory/ntap-20231027-0002/","https://www.debian.org/security/2023/dsa-5480","https://www.debian.org/security/2023/dsa-5492"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26790 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned read There is chip (ls1028a) errata: The SoC may hang on 16 byte unaligned read transactions by QDMA. Unaligned read transactions initiated by QDMA may stall in the NOC (Network On-Chip), causing a deadlock condition. Stalled transactions will trigger completion timeouts in PCIe controller. Workaround: Enable prefetch by setting the source descriptor prefetchable bit ( SD[PF] = 1 ). Implement this workaround. | ["https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce","https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa","https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da","https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367","https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e","https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471","https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580","https://git.kernel.org/stable/c/106c1ac953a66556ec77456c46e818208d3a9bce","https://git.kernel.org/stable/c/237ecf1afe6c22534fa43abdf2bf0b0f52de0aaa","https://git.kernel.org/stable/c/518d78b4fac68cac29a263554d7f3b19da99d0da","https://git.kernel.org/stable/c/5b696e9c388251f1c7373be92293769a489fd367","https://git.kernel.org/stable/c/9d739bccf261dd93ec1babf82f5c5d71dd4caa3e","https://git.kernel.org/stable/c/ad2f8920c314e0a2d9e984fc94b729eca3cda471","https://git.kernel.org/stable/c/bb3a06e9b9a30e33d96aadc0e077be095a4f8580","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52493 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable] | ["https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b","https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e","https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690","https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece","https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830","https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e","https://git.kernel.org/stable/c/01bd694ac2f682fb8017e16148b928482bc8fa4b","https://git.kernel.org/stable/c/20a6dea2d1c68d4e03c6bb50bc12e72e226b5c0e","https://git.kernel.org/stable/c/3c5ec66b4b3f6816f3a6161538672e389e537690","https://git.kernel.org/stable/c/6e4c84316e2b70709f0d00c33ba3358d9fc8eece","https://git.kernel.org/stable/c/b8eff20d87092e14cac976d057cb0aea2f1d0830","https://git.kernel.org/stable/c/eaefb9464031215d63c0a8a7e2bfaa00736aa17e","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26614 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's spinlocks once When I run syz's reproduction C program locally, it causes the following issue: pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7 30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908 RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000 R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321) inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533) net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469) tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP: 0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003 RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20 </TASK> The issue triggering process is analyzed as follows: Thread A Thread B tcp_v4_rcv //receive ack TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE) inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated--- | ["https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02","https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2","https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a","https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855","https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882","https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3","https://git.kernel.org/stable/c/168e7e599860654876c2a1102a82610285c02f02","https://git.kernel.org/stable/c/198bc90e0e734e5f98c3d2833e8390cac3df61b2","https://git.kernel.org/stable/c/3982fe726a63fb3de6005e534e2ac8ca7e0aca2a","https://git.kernel.org/stable/c/b1e0a68a0cd2a83259c444f638b417a8fffc6855","https://git.kernel.org/stable/c/bc99dcedd2f422d602516762b96c8ef1ae6b2882","https://git.kernel.org/stable/c/d86cc6ab33b085eaef27ea88b78fc8e2375c0ef3","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-38409 | Medium | fixed |
|
An issue was discovered in set_con2fb_map in drivers/video/fbdev/core/fbcon.c in the Linux kernel before 6.2.12. Because an assignment occurs only for the first vc, the fbcon_registered_fb and fbcon_display arrays can be desynchronized in fbcon_mode_deleted (the con2fb_map points at the old fb_info). | ["https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d","https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.2.12","https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=fffb0b52d5258554c645c966c6cbef7de50b851d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26726 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. This is normal for normal files, but the free space cache inode is special. We always expect the extent map to be correct. Thus the second time through we end up with a bogus extent map. Since we're deprecating this feature, the most straightforward way to fix this is to simply skip dropping the extent map range for this failed range. I shortened the test by using error injection to stress the area to make it easier to reproduce. With this patch in place we no longer panic with my error injection test. | ["https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555","https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade","https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7","https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e","https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555","https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade","https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7","https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-6560 | Medium | N/A | An out-of-bounds memory access flaw was found in the io_uring SQ/CQ rings functionality in the Linux kernel. This issue could allow a local user to crash the system. | ["http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html","https://access.redhat.com/security/cve/CVE-2023-6560","https://bugzilla.redhat.com/show_bug.cgi?id=2253249","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/","https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/","http://packetstormsecurity.com/files/176405/io_uring-__io_uaddr_map-Dangerous-Multi-Page-Handling.html","https://access.redhat.com/security/cve/CVE-2023-6560","https://bugzilla.redhat.com/show_bug.cgi?id=2253249","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/AU4NHBDEDLRW33O76Y6LFECEYNQET5GZ/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UCQIPFUQXKXRCH5Y4RP3C5NK4IHNBNVK/","https://patchwork.kernel.org/project/io-uring/patch/20231130194633.649319-2-axboe@kernel.dk/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26764 | Low | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the following kernel warning appears: WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8 Call trace: kiocb_set_cancel_fn+0x9c/0xa8 ffs_epfile_read_iter+0x144/0x1d0 io_read+0x19c/0x498 io_issue_sqe+0x118/0x27c io_submit_sqes+0x25c/0x5fc __arm64_sys_io_uring_enter+0x104/0xab0 invoke_syscall+0x58/0x11c el0_svc_common+0xb4/0xf4 do_el0_svc+0x2c/0xb0 el0_svc+0x2c/0xa4 el0t_64_sync_handler+0x68/0xb4 el0t_64_sync+0x1a4/0x1a8 Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is submitted by libaio. | ["https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487","https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6","https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f","https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942","https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760","https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353","https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7","https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f","https://git.kernel.org/stable/c/18f614369def2a11a52f569fe0f910b199d13487","https://git.kernel.org/stable/c/1dc7d74fe456944a9b1c57bd776280249f441ac6","https://git.kernel.org/stable/c/337b543e274fe7a8f47df3c8293cc6686ffa620f","https://git.kernel.org/stable/c/b4eea7a05ee0ab5ab0514421e6ba8c5d249cf942","https://git.kernel.org/stable/c/b820de741ae48ccf50dd95e297889c286ff4f760","https://git.kernel.org/stable/c/d7b6fa97ec894edd02f64b83e5e72e1aa352f353","https://git.kernel.org/stable/c/e7e23fc5d5fe422827c9a43ecb579448f73876c7","https://git.kernel.org/stable/c/ea1cd64d59f22d6d13f367d62ec6e27b9344695f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52621 | High | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: <TASK> ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ? __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> | ["https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d","https://git.kernel.org/stable/c/3516f93cc63d956e1b290ae4b7bf2586074535a0","https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d","https://git.kernel.org/stable/c/82f2df94dac1aa9b879e74d1f82ba1b631bdc612","https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304","https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3","https://git.kernel.org/stable/c/169410eba271afc9f0fb476d996795aa26770c6d","https://git.kernel.org/stable/c/483cb92334cd7f1d5387dccc0ab5d595d27a669d","https://git.kernel.org/stable/c/c7f1b6146f4a46d727c0d046284c28b6882c6304","https://git.kernel.org/stable/c/d6d6fe4bb105595118f12abeed4a7bdd450853f3"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-3439 | Medium | fixed |
|
A flaw was found in the MCTP protocol in the Linux kernel. The function mctp_unregister() reclaims the device's relevant resource when a netcard detaches. However, a running routine may be unaware of this and cause the use-after-free of the mdev->addrs object, potentially leading to a denial of service. | ["http://www.openwall.com/lists/oss-security/2023/07/02/1","https://bugzilla.redhat.com/show_bug.cgi?id=2217915","https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269","http://www.openwall.com/lists/oss-security/2023/07/02/1","https://bugzilla.redhat.com/show_bug.cgi?id=2217915","https://github.com/torvalds/linux/commit/b561275d633bcd8e0e8055ab86f1a13df75a0269"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26878 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1) dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue. | ["https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25","https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5","https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0","https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0","https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877","https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754","https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1","https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f","https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7","https://git.kernel.org/stable/c/1ca72a3de915f87232c9a4cb9bebbd3af8ed3e25","https://git.kernel.org/stable/c/40a673b4b07efd6f74ff3ab60f38b26aa91ee5d5","https://git.kernel.org/stable/c/49669f8e7eb053f91d239df7b1bfb4500255a9d0","https://git.kernel.org/stable/c/61380537aa6dd32d8a723d98b8f1bd1b11d8fee0","https://git.kernel.org/stable/c/6afc9f4434fa8063aa768c2bf5bf98583aee0877","https://git.kernel.org/stable/c/7f9e833fc0f9b47be503af012eb5903086939754","https://git.kernel.org/stable/c/8514899c1a4edf802f03c408db901063aa3f05a1","https://git.kernel.org/stable/c/d0aa72604fbd80c8aabb46eda00535ed35570f1f","https://git.kernel.org/stable/c/f2649d98aa9ca8623149b3cb8df00c944f5655c7","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26698 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel"), napi_disable was getting called for all channels, including all subchannels without confirming if they are enabled or not. This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() has finished running but nvdev->subchan_work has not started yet. netvsc_subchan_work() -> rndis_set_subchannel() has not created the sub-channels and because of that netvsc_sc_open() is not running. netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which netvsc_subchan_work did not run. netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the opposite. Now during netvsc_device_remove(), when napi_disable is called for those subchannels, napi_disable gets stuck on infinite msleep. This fix addresses this problem by ensuring that napi_disable() is not getting called for non-enabled NAPI struct. But netif_napi_del() is still necessary for these non-enabled NAPI struct for cleanup purpose. Call trace: [ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 [ 654.568030] Call Trace: [ 654.571221] <TASK> [ 654.573790] __schedule+0x2d6/0x960 [ 654.577733] schedule+0x69/0xf0 [ 654.581214] schedule_timeout+0x87/0x140 [ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 [ 654.590291] msleep+0x2d/0x40 [ 654.593625] napi_disable+0x2b/0x80 [ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] [ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] [ 654.611101] ? do_wait_intr+0xb0/0xb0 [ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] [ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] | ["https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd","https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b","https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518","https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a","https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f","https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11","https://git.kernel.org/stable/c/0e8875de9dad12805ff66e92cd5edea6a421f1cd","https://git.kernel.org/stable/c/22a77c0f5b8233237731df3288d067af51a2fd7b","https://git.kernel.org/stable/c/48a8ccccffbae10c91d31fc872db5c31aba07518","https://git.kernel.org/stable/c/7656372ae190e54e8c8cf1039725a5ea59fdf84a","https://git.kernel.org/stable/c/9ec807e7b6f5fcf9499f3baa69f254bb239a847f","https://git.kernel.org/stable/c/e0526ec5360a48ad3ab2e26e802b0532302a7e11","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52644 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated--- | ["https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455","https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010","https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240","https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436","https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08","https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc","https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83","https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d","https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610","https://git.kernel.org/stable/c/04a2b6eff2ae1c19cb7f41e803bcbfaf94c06455","https://git.kernel.org/stable/c/1824f942527f784a19e01eac2d9679a21623d010","https://git.kernel.org/stable/c/31aaf17200c336fe258b70d39c40645ae19d0240","https://git.kernel.org/stable/c/4049a9f80513a6739c5677736a4c88f96df1b436","https://git.kernel.org/stable/c/49f067726ab01c87cf57566797a8a719badbbf08","https://git.kernel.org/stable/c/9636951e4468f02c72cc75a82dc65d003077edbc","https://git.kernel.org/stable/c/bc845e2e42cae95172c04bf29807c480f51a2a83","https://git.kernel.org/stable/c/c67698325c68f8768db858f5c87c34823421746d","https://git.kernel.org/stable/c/f1cf77bb870046a6111a604f7f7fe83d1c8c9610","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26712 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: powerpc/kasan: Fix addr error caused by page alignment In kasan_init_region, when k_start is not page aligned, at the begin of for loop, k_cur = k_start & PAGE_MASK is less than k_start, and then `va = block + k_cur - k_start` is less than block, the addr va is invalid, because the memory address space from va to block is not alloced by memblock_alloc, which will not be reserved by memblock_reserve later, it will be used by other places. As a result, memory overwriting occurs. for example: int __init __weak kasan_init_region(void *start, size_t size) { [...] /* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */ block = memblock_alloc(k_end - k_start, PAGE_SIZE); [...] for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) { /* at the begin of for loop * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400) * va(dcd96c00) is less than block(dcd97000), va is invalid */ void *va = block + k_cur - k_start; [...] } [...] } Therefore, page alignment is performed on k_start before memblock_alloc() to ensure the validity of the VA address. | ["https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe","https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058","https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882","https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6","https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0","https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25","https://git.kernel.org/stable/c/0516c06b19dc64807c10e01bb99b552bdf2d7dbe","https://git.kernel.org/stable/c/0c09912dd8387e228afcc5e34ac5d79b1e3a1058","https://git.kernel.org/stable/c/230e89b5ad0a33f530a2a976b3e5e4385cb27882","https://git.kernel.org/stable/c/2738e0aa2fb24a7ab9c878d912dc2b239738c6c6","https://git.kernel.org/stable/c/4a7aee96200ad281a5cc4cf5c7a2e2a49d2b97b0","https://git.kernel.org/stable/c/70ef2ba1f4286b2b73675aeb424b590c92d57b25","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26846 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: nvme-fc: do not wait in vain when unloading module The module exit path has race between deleting all controllers and freeing 'left over IDs'. To prevent double free a synchronization between nvme_delete_ctrl and ida_destroy has been added by the initial commit. There is some logic around trying to prevent from hanging forever in wait_for_completion, though it does not handling all cases. E.g. blktests is able to reproduce the situation where the module unload hangs forever. If we completely rely on the cleanup code executed from the nvme_delete_ctrl path, all IDs will be freed eventually. This makes calling ida_destroy unnecessary. We only have to ensure that all nvme_delete_ctrl code has been executed before we leave nvme_fc_exit_module. This is done by flushing the nvme_delete_wq workqueue. While at it, remove the unused nvme_fc_wq workqueue too. | ["https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17","https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c","https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2","https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982","https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9","https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67","https://git.kernel.org/stable/c/085195aa90a924c79e35569bcdad860d764a8e17","https://git.kernel.org/stable/c/0bf567d6d9ffe09e059bbdfb4d07143cef42c75c","https://git.kernel.org/stable/c/4f2c95015ec2a1899161be6c0bdaecedd5a7bfb2","https://git.kernel.org/stable/c/70fbfc47a392b98e5f8dba70c6efc6839205c982","https://git.kernel.org/stable/c/baa6b7eb8c66486bd64608adc63fe03b30d3c0b9","https://git.kernel.org/stable/c/c0882c366418bf9c19e1ba7f270fe377a9bf5d67","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-33951 | Medium | N/A | A race condition vulnerability was found in the vmwgfx driver in the Linux kernel. The flaw exists within the handling of GEM objects. The issue results from improper locking when performing operations on an object. This flaw allows a local privileged user to disclose information in the context of the kernel. | ["https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33951","https://bugzilla.redhat.com/show_bug.cgi?id=2218195","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/","https://access.redhat.com/errata/RHSA-2023:6583","https://access.redhat.com/errata/RHSA-2023:6901","https://access.redhat.com/errata/RHSA-2023:7077","https://access.redhat.com/errata/RHSA-2024:1404","https://access.redhat.com/errata/RHSA-2024:4823","https://access.redhat.com/errata/RHSA-2024:4831","https://access.redhat.com/security/cve/CVE-2023-33951","https://bugzilla.redhat.com/show_bug.cgi?id=2218195","https://www.zerodayinitiative.com/advisories/ZDI-CAN-20110/"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26727 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one. | ["https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f","https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468","https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d","https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430","https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb","https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f","https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f","https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468","https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d","https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430","https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303ebf9dfb","https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52569 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node's tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items. | ["https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9","https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f","https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51","https://git.kernel.org/stable/c/2c58c3931ede7cd08cbecf1f1a4acaf0a04a41a9","https://git.kernel.org/stable/c/39c4a9522db0072570d602e9b365119e17fb9f4f","https://git.kernel.org/stable/c/d10fd53393cc5de4b9cf1a4b8f9984f0a037aa51"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-1075 | Low | N/A | A flaw was found in the Linux Kernel. The tls_is_tx_ready() incorrectly checks for list emptiness, potentially accessing a type confused entry to the list_head, leaking the last byte of the confused field that overlaps with rec->tx_ready. | ["https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ffe2a22562444720b05bdfeb999c03e810d84cbb","https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ffe2a22562444720b05bdfeb999c03e810d84cbb"] | pkg:generic/linux-kernel@5.15.26.container | |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-0340 | Medium | fixed |
|
A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file. | ["https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/errata/RHSA-2024:9315","https://access.redhat.com/errata/RHSA-2025:7526","https://access.redhat.com/security/cve/CVE-2024-0340","https://bugzilla.redhat.com/show_bug.cgi?id=2257406","https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/","https://access.redhat.com/errata/RHSA-2024:3618","https://access.redhat.com/errata/RHSA-2024:3627","https://access.redhat.com/security/cve/CVE-2024-0340","https://bugzilla.redhat.com/show_bug.cgi?id=2257406","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html","https://lists.debian.org/debian-lts-announce/2024/06/msg00020.html","https://lore.kernel.org/lkml/5kn47peabxjrptkqa6dwtyus35ahf4pcj4qm4pumse33kxqpjw@mec4se5relrc/T/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-52478 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a "device-connected" packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { ... hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); ... hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace's pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 ... Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 ... Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: ---truncated--- | ["https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1","https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528","https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c","https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5","https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b","https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452","https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e","https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d","https://git.kernel.org/stable/c/093af62c023537f097d2ebdfaa0bc7c1a6e874e1","https://git.kernel.org/stable/c/28ddc1e0b898291323b62d770b1b931de131a528","https://git.kernel.org/stable/c/44481b244fcaa2b895a53081d6204c574720c38c","https://git.kernel.org/stable/c/ca0c4cc1d215dc22ab0e738c9f017c650f3183f5","https://git.kernel.org/stable/c/cd0e2bf7fb22fe9b989c59c42dca06367fd10e6b","https://git.kernel.org/stable/c/dac501397b9d81e4782232c39f94f4307b137452","https://git.kernel.org/stable/c/f7b2c7d9831af99369fe8ad9b2a68d78942f414e","https://git.kernel.org/stable/c/fd72ac9556a473fc7daf54efb6ca8a97180d621d"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26910 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix performance regression in swap operation The patch "netfilter: ipset: fix race condition between swap/destroy and kernel side add/del/test", commit 28628fa9 fixes a race condition. But the synchronize_rcu() added to the swap function unnecessarily slows it down: it can safely be moved to destroy and use call_rcu() instead. Eric Dumazet pointed out that simply calling the destroy functions as rcu callback does not work: sets with timeout use garbage collectors which need cancelling at destroy which can wait. Therefore the destroy functions are split into two: cancelling garbage collectors safely at executing the command received by netlink and moving the remaining part only into the rcu callback. | ["https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c","https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb","https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001","https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05","https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397","https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49","https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225","https://git.kernel.org/stable/c/653bc5e6d9995d7d5f497c665b321875a626161c","https://git.kernel.org/stable/c/970709a67696b100a57b33af1a3d75fc34b747eb","https://git.kernel.org/stable/c/97f7cf1cd80eeed3b7c808b7c12463295c751001","https://git.kernel.org/stable/c/a24d5f2ac8ef702a58e55ec276aad29b4bd97e05","https://git.kernel.org/stable/c/b93a6756a01f4fd2f329a39216f9824c56a66397","https://git.kernel.org/stable/c/c2dc077d8f722a1c73a24e674f925602ee5ece49","https://git.kernel.org/stable/c/c7f2733e5011bfd136f1ca93497394d43aa76225","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-24448 | Low | fixed |
|
An issue was discovered in fs/nfs/dir.c in the Linux kernel before 5.16.5. If an application sets the O_DIRECTORY flag, and tries to open a regular file, nfs_atomic_open() performs a regular lookup. If a regular file is found, ENOTDIR should occur, but the server instead returns uninitialized data in the file descriptor. | ["https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac795161c93699d600db16c1a8cc23a65a1eceaf","https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a","https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/all/67d6a536-9027-1928-99b6-af512a36cd1a%40huawei.com/T/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://www.spinics.net/lists/stable/msg531976.html","https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.5","https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ac795161c93699d600db16c1a8cc23a65a1eceaf","https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a","https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf","https://lists.debian.org/debian-lts-announce/2022/03/msg00011.html","https://lists.debian.org/debian-lts-announce/2022/03/msg00012.html","https://lore.kernel.org/all/67d6a536-9027-1928-99b6-af512a36cd1a%40huawei.com/T/","https://www.debian.org/security/2022/dsa-5092","https://www.debian.org/security/2022/dsa-5096","https://www.spinics.net/lists/stable/msg531976.html"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-4662 | Medium | fixed |
|
A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system. | ["https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/","https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/","https://lore.kernel.org/all/20220913140355.910732567%40linuxfoundation.org/","https://lore.kernel.org/all/CAB7eexLLApHJwZfMQ=X-PtRhw0BgO+5KcSMS05FNUYejJXqtSA%40mail.gmail.com/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2023-42756 | Medium | fixed |
|
A flaw was found in the Netfilter subsystem of the Linux kernel. A race condition between IPSET_CMD_ADD and IPSET_CMD_SWAP can lead to a kernel panic due to the invocation of `__ip_set_put` on a wrong `set`. This issue may allow a local user to crash the system. | ["https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-42756","https://bugzilla.redhat.com/show_bug.cgi?id=2239848","https://seclists.org/oss-sec/2023/q3/242","https://access.redhat.com/errata/RHSA-2024:2394","https://access.redhat.com/security/cve/CVE-2023-42756","https://bugzilla.redhat.com/show_bug.cgi?id=2239848","https://lists.debian.org/debian-lts-announce/2023/10/msg00027.html","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GISYSL3F6WIEVGHJGLC2MFNTUXHPTKQH/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GPMICQ2HVZO5UAM5KPXHAZKA2U3ZDOO6/","https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/V5PDNWPKAP3WL5RQZ4RIDS6MG32OHH5R/","https://seclists.org/oss-sec/2023/q3/242"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2022-2503 | Medium | fixed |
|
Dm-verity is used for extending root-of-trust to root filesystems. LoadPin builds on this property to restrict module/firmware loads to just the trusted root filesystem. Device-mapper table reloads currently allow users with root privileges to switch out the target with an equivalent dm-linear target and bypass verification till reboot. This allows root to bypass LoadPin and can be used to load untrusted and unverified kernel modules and firmware, which implies arbitrary kernel execution and persistence for peripherals that do not verify firmware updates. We recommend upgrading past commit 4caae58406f8ceb741603eee460d79bacca9b1b5 | ["https://github.com/google/security-research/security/advisories/GHSA-6vq3-w69p-w63m","https://security.netapp.com/advisory/ntap-20230214-0005/","https://github.com/google/security-research/security/advisories/GHSA-6vq3-w69p-w63m","https://security.netapp.com/advisory/ntap-20230214-0005/"] | pkg:generic/linux-kernel@5.15.26.container |
| linux-kernel | 5.15.26.container | linux-kernel | CVE-2024-26743 | Medium | fixed |
|
In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp error flow Avoid the following warning by making sure to free the allocated resources in case that qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0 do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130 exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ? do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace 888a9b92e04c5c97 ]-- | ["https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a","https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a","https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928","https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc","https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298","https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6","https://git.kernel.org/stable/c/135e5465fefa463c5ec93c4eede48b9fedac894a","https://git.kernel.org/stable/c/5639414a52a29336ffa1ede80a67c6d927acbc5a","https://git.kernel.org/stable/c/5ba4e6d5863c53e937f49932dee0ecb004c65928","https://git.kernel.org/stable/c/7f31a244c753aacf40b71d01f03ca6742f81bbbc","https://git.kernel.org/stable/c/95175dda017cd4982cd47960536fa1de003d3298","https://git.kernel.org/stable/c/bab8875c06ebda5e01c5c4cab30022aed85c14e6","https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"] | pkg:generic/linux-kernel@5.15.26.container |